Product Launch
anonymous
24 points
30 comments
Posted21 days agoActive15 days ago
Logging Library
hackers.publaunchedlibrarydevelopers
Key Features
logging functionalitycustomizable
loggingProgrammingopen-source
Key Features
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.
I'd hate that, because I like the idea about a standard for telemetry, but the reality is that most projects don't need this amount of insight (when you have to give up so much speed)
What operating system and browser did you use to write your post?
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".
The thing is: A bug does not invalidate enterprise adoption - Microsoft ist a good example.
"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)
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
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.
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.
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.
I'm curious if this is enough https://nodejs.org/api/diagnostics_channel.html
I don't like the js hotel libraries, their docs feel deliberately obtuse
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.