I don't think the post is an unreasonable complaint. The fact that you have to even think about how to get logs out of your application is insane, never mind all the hoops you need here. Logging should be a first class citizen in anything that goes to production.
Interesting, because that is hardly so in most frameworks, logging requires additional libraries and configuration almost everywhere.
In most languages and frameworks logging is as simple as import, initialize, done. Here it's far from it.
Really, which ones?
Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.
> .NET
I think you haven't used .NET in a while. Nowadays, logging is absurdly easy to configure. Heck, you usually don't even need to configure it, because the basics are already included in most templates. You just use the Logger class and it works.
The only time you have to spend more than 30 minutes on it is when you use some external logging libraries. And most of them are quite sane and simple to use, because it's so easy to create a custom logging provider.
I use it almost every day.
Java, .NET and nodejs are all over the place around here.
The point was without configuration.
Logger class doesn't do the work for production monitoring, without additional configuration so that its output appears on the necessary production dashboards.
Log4j can be as simple as add the dependency and you're good to go. Of course, you can do fancier setups and bridge your logs wherever where it is more work, but out of the box, it's very straightforward and batteries included. I have a very hard time believing you're seriously arguing the case that some of the most commonly used languages don't have good options for logging.
Which Java framework has log4j working out of the box for serious production deployment?
Spring Boot for example, which is arguably one of the most common ways to do Java anything these days. If you're trying to make a point, it would be considerably easier if you just said what you mean, because so far you're not making one. You could've easily looked up any of these questions.
Wrong again.
Spring Boot doesn't provide a serious production quality deployment without configuration.
Bare bones logging into standard out, yes.
That isn't production quality.
Production quality is telemetry logging, log rotation and zipping, forwarding logs to Kibana or Datadog dashboard.
This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than telling.
Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case.
Word vomit into standard output isn't production quality.
It seems you might've missed functional reading class. The first thing I led with was that you need to import and initialize logging which covers both of those. You're the only one insinuating the strawmen you're arguing against. This isn't Reddit, surely you can do better.
I was there, initialize logging is configuration be it by code or settings files, which apparently isn't needed, an import does everything to show on production monitoring dashboards.
I do whatever I feel like, you're the one that started down this thread, don't complain where it goes.