It seems like the normal and rational choice to not include logging to me.
Java included 'java.util.logging'. No one uses it because it's bad, everyone just uses slf4j as the generic facade instead, and then some underlying implementation.
Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logrus, etc.
Golang is also a disaster in that the stdlib has "log/slog" as the approved logging method, but i.e. the 'http.Server.ErrorLog' is the old 'log.Logger' you're not supposed to use, and for backwards compatibility reasons it's stuck that way. The go stdlib is full of awkward warts because it maintains backwards compatibility, and also included a ton of extra knobs that they got wrong.
The argument of structured vs unstructured logging, arguments around log levels (glog style numeric levels, trace/debug/info/warn/error/critical or some subset, etc), how to handle lazy logging or lazy computations in logging, etc etc, it's all enough that the stdlib can't easily make a choice that will make everyone happy.
Rust as a language has provided enough that the community can make a sl4j like facade (conveniently, the clearly named 'log' crate seems to be the winner there), so there's no reason it has to be in the stdlib.
Python includes logging, and packages generally use it. It's far from perfect, but it's important to have at least a standard interface so that all components use it in concert. When you have a proliferation of logging libraries with no standard, other packages either don't do any logging at all, or do it in idiosyncratic ways that are hard (or impossible) to integrate.
> Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logrus, etc.
I honestly don't know how common it is to use zap, logrus and co on new projects anymore. I know I always go for slog.
> Golang is also a disaster in that the stdlib has "log/slog" as the approved logging method, but i.e. the 'http.Server.ErrorLog' is the old 'log.Logger' you're not supposed to use, and for backwards compatibility reasons it's stuck that way. The go stdlib is full of awkward warts because it maintains backwards compatibility, and also included a ton of extra knobs that they got wrong.
This isn't a practical problem at all. First of all, the stdlib shouldn't make backwards-incompatible changes just for the sake of logging. Second, slog.NewLogLogger()[0] exists as a way to get log.Loggers to be used with things that rely on the old log.Logger.
Rust's standard library hasn't received any major additions since 1.0 in 2015, back when nobody was writing web services in Rust so no one needed logging.
It seems like the normal and rational choice to not include logging to me.
Java included 'java.util.logging'. No one uses it because it's bad, everyone just uses slf4j as the generic facade instead, and then some underlying implementation.
Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logrus, etc.
Golang is also a disaster in that the stdlib has "log/slog" as the approved logging method, but i.e. the 'http.Server.ErrorLog' is the old 'log.Logger' you're not supposed to use, and for backwards compatibility reasons it's stuck that way. The go stdlib is full of awkward warts because it maintains backwards compatibility, and also included a ton of extra knobs that they got wrong.
The argument of structured vs unstructured logging, arguments around log levels (glog style numeric levels, trace/debug/info/warn/error/critical or some subset, etc), how to handle lazy logging or lazy computations in logging, etc etc, it's all enough that the stdlib can't easily make a choice that will make everyone happy.
Rust as a language has provided enough that the community can make a sl4j like facade (conveniently, the clearly named 'log' crate seems to be the winner there), so there's no reason it has to be in the stdlib.
Python includes logging, and packages generally use it. It's far from perfect, but it's important to have at least a standard interface so that all components use it in concert. When you have a proliferation of logging libraries with no standard, other packages either don't do any logging at all, or do it in idiosyncratic ways that are hard (or impossible) to integrate.
> Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logrus, etc.
I honestly don't know how common it is to use zap, logrus and co on new projects anymore. I know I always go for slog.
> Golang is also a disaster in that the stdlib has "log/slog" as the approved logging method, but i.e. the 'http.Server.ErrorLog' is the old 'log.Logger' you're not supposed to use, and for backwards compatibility reasons it's stuck that way. The go stdlib is full of awkward warts because it maintains backwards compatibility, and also included a ton of extra knobs that they got wrong.
This isn't a practical problem at all. First of all, the stdlib shouldn't make backwards-incompatible changes just for the sake of logging. Second, slog.NewLogLogger()[0] exists as a way to get log.Loggers to be used with things that rely on the old log.Logger.
[0] https://pkg.go.dev/log/slog#NewLogLogger
Rust's standard library hasn't received any major additions since 1.0 in 2015, back when nobody was writing web services in Rust so no one needed logging.
This is patently false. The majority of the "features" that get added to Rust in every release are additions to the standard library.
Depends on your definition of "major". Small utility functions are added on nearly every release, but they definitely aren't major.
println!() exists but there are more fancy crates like http://lib.rs/tracing and https://lib.rs/crates/log