I couldn't find a logging library that worked for my library, so I made one

industry-proven and mature libs like LOG4J or LOG4Net are not sufficient?

You mean this log4j [0] with major vulnerabilities the industry missed for nearly a decade?

[0] https://en.wikipedia.org/wiki/Log4Shell

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?

Have you used ever OpenSSL? :-D

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

That was less my point, and more that "battle-tested" doesn't have to be a cudgel to argue against in-house projects, especially when considering defect rates (the more-general solution is very often slower and buggier to support the features you don't need).

Maybe we should differ the terms:

"industry proven" -> MS/Windows -> yes

"battle tested" -> MS Windows -> you may discuss? :-D

If there is an inhouse solution available and which is really working, then Id not introduce an externa component here. If you start from zero, then using a pre-existing component should be the path, in my perception. Sure, one can waste time write a logger, but should have e.g. Bezos spent time coding on a logging lib or care about the webshop and use an existing lib for that - but in most cases it does not payoff to do whatever self-implementation-voodoo someone imagines: its just a waste of time. (Esp. since most companies do not take off enough to make such an investment plausible)

Unary thinking has no place when considering software quality or security. Just because things have vulnerabilities does not mean that the category, severity, and frequency of them is a irrelevant consideration.

The Log4j vulnerability was effectively calling eval() on user input strings. That is utter incompetence to the extreme with immediately obvious, catastrophic consequences to anybody with any knowledge whatsoever of software security. That should be immediately disqualifying like a construction company delivering a house without a roof. "Oh yeah, anybody could forget to put a roof on a house. We can not hold them responsible for every little mistake." is nonsense. Basic, egregious errors are disqualifying.

Now, it could be the case that everything is horribly defective and inadequate and everybody is grossly incompetent. That does not somehow magically make inadequacy adequate and appropriate for use. It is just that in software people get away with using systems unfit for purpose because they had "no choice but to use substandard components and harm their users so they could make money".

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.

It's Strings. They go somewhere. The interface writes itself: Consumer<String>.

At my absolute fanciest, I use a Queue, some terminal colouring, separate stderr from stdout, and write some short-hand functions (warn, err, info, etc.).

These are the bugs I don't have: https://github.com/apache/logging-log4j2/issues

In the .Net space log4net is horrifically outdated and there's zero reason to use it today. Logging for modern .Net apps and libraries should be built on the Microsoft.Extensions.Logging abstractions which provide the type of features covered in TFA. They also provide a clear separation between generating log events in code and determining where & how logs are stored. For basic needs you can use simple log writers that tie in directly with MEL, or for advanced needs link MEL with Serilog so that you can use its sinks and log processing pipeline.

The article is discussing JavaScript, are you discussing JavaScript?