Hacker News Reader

Comment by seniorsassycat | Hacker News Reader

IMO until the abstract logging interface is built into the language, or standard library, we'll keep building different log libraries and adapters between them, and shipping libraries without logging.

It makes me actively disinterested in these libraries. I just want some built in interface with levels, hierarchy, and structured logging

View on HN

This is one of the things Elixir got right on day 1, all the libraries in the ecosystem use the standard library and it makes dealing with logs so much easier compared to other languages.

This slows down innovation.

In Java it is common to use the MDC support of slf4j. You can add to metadata in thread local variables, so that you don't have to add it at every logging site.

Any precedent for language agnostic behavior (I genuinely don’t know)? Would be keen to have a common interface that languages implement into their standard libraries or keywords

OTEL perhaps

Java has the java.util.logging classes.

Java historically has had so many logging frameworks it needs logging framework adapters to deal with the problem that in any significant program you will end up with dependencies that log in incompatible ways :/

It probably has the most complex and messy logging story of any language - but at least the solutions are very mature at this point.

Not a good example, as the de-facto logging interface for Java was SLF4J.

Though I myself prefer Log4J2, as I'm already using Log4J2 as the concrete logging implementation.

Why do you prefer Log4j2 over the slf4j api and why over logback as the backend?

I prefer Log4J2 built-in JSON Template Layout to Logback's various JSON output solution.

The API of Log4J2 and SLF4J v2 are similar enough that it does not matter for basic usage, I don't see the benefit of SLF4J in a project that's already using Log4J2.

Swift has a de-facto logging library: swift-log (by Apple, with levels and structured logging; not sure about hierarchy as I don’t know what you mean by that).

Probably, a hierarchy of different loggers.

You're right that people will continue building their own libraries. I also wish this was all built-in so you wouldn't need something like loglayer.

This is how .net does this as well. You write logs via ILogger interface and then wire it up to a logging library of any flavor.

ILogger is not in the BCL. Its part of the Microsoft.Extensions family of libraries.

Though today much of the Microsoft.Extensions family is considered BCL by most users, especially in the way it is documented as "Core functionality" (the "Generic Host" model uses a lot of Microsoft.Extensions, up front in .NET documentation today) and also in the way that the majority of it (especially in this case of Microsoft.Extensions.Logging) is source controlled side-by-side with most of the BCL, including almost all of System.**: https://github.com/dotnet/runtime/tree/main/src/libraries

(There are some of Microsoft.Extensions that exist outside of dotnet/runtime in dotnet/extensions: https://github.com/dotnet/extensions/tree/main/src/Libraries)

Reply on news.ycombinator.com