Aside from what some other users have said, logging is fundamentally an observable side-effect of your library. It’s now a behavior that can become load-bearing — and putting it in library code forces this exposed behavior on the consumer.

As a developer, this gets frustrating. I want to present a clean and coherent output to my callers, and poorly-authored libraries ruin that — especially if they offer no mechanism to disable it.

It’s also just _sloppy_ in many cases. Well-designed library code often shouldn’t even need to log in the first place because it should clearly articulate each units side-effects; the composition of which should become clear to understand. Sadly, “design” has become a lost art in modern software development.

It depends a lot on the language, but in my field libraries that have their own logging implementation and that don't provide hooks to override it cause big problems for me because I send all the logs to the same central logging client that forwards it to the same central logging server for aggregation. Your logging probably dumps it to a file, or it writes it to STDOUT, or something similar, in which case now I have to pipe all of that data in two places by doing something hacky.

There are some language ecosystems that have good logging systems like Java which I would be totally fine with. But systems languages like C/C++ that don't have a core concept of a "log message" are a pain to deal with when the library author decides to stream some text message somewhere. Which is probably a good argument for not using those languages in some circles, but sometimes you have to use what you have.

So it's not really a blanket "don't do it" but you should carefully consider whether there's some well-known mechanism for application authors to intake and manage your logging output, and if that doesn't exist you should provide some hooks or consider not logging at all except with some control.

It tends to break composability.

The behavior of the library logging can be incompatible with the architectural requirements of the application in dimensions that are independent of the library functionality. It requires the user to understand the details of the library's logging implementation. Even if documented, design choices for the logging will automatically disqualify the library for some applications and use cases.

Is writing the log a blocking call? Does it allocate? Synchronous or async? What is the impact on tail latencies? How does it interact with concurrency? Etc.

Because they have to be compatible with your logging implementation, and they were written first.

Any log produced directly by a library will just be a "what" detached from any semblance of a "why".

Because libraries don't know where or even how the user wants it to log.

Rust also.

Similar to this: OpenTelemetry has a golang library that allows you to instrument your library so that you can send traces, logs, etc. to an OTEL endpoint, but that instrumentation doesn't actually do anything unless the developer of the actual application uses a separate golang library to actually trigger, collect, and transmit those traces. Otherwise it's basically a no-op.

So you don’t use any software that has had a security vulnerability?

What operating system and browser did you use to write your post?

If this library became untouchable for you, slf4j/logback is better and very popular alternative. I‘d say the design of slf4j is actually perfect.

Have you used ever OpenSSL? :-D

The thing is: A bug does not invalidate enterprise adoption - Microsoft ist a good example.

Which OpenTel impl isn't awfully glued together? When I looked at Rust implementation... I felt really bad. I feel like rolling my own logging is the only option.