4 ms·

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of sim

by Pxtl 5y ago

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.

markmark 5y ago
I don't use java and have never touched log4j, but structured logs are utterly fantastic and combined with an appropriate log server are far more useful than plain text.
- lmm 5y ago
  Structured logging is great, but it's vital to keep them structured all the way through. Having an API where you pass a string and then something on the other side tries to parse that string back into structured data is a recipe for disaster.
- throw_m239339 5y ago
  There is a difference between structured log and something that interprets these logs to create shells down the stack, inside a log library... Nobody is questioning the benefits of structured logs here. The log library itself shouldn't be interpreting these logs. It's like a HTTP framework... triggering a printer, why the hell would it be doing that by default? Seems to me that Log4j is doing to many things, including things it shouldn't be concerned with, as a log library.
  - markmark 5y ago
    > Nobody is questioning the benefits of structured logs here. The guy I replied to was literally saying we should only log plain text and that doing anything more complicated is "emblematic of the crisis the industry is in".
- jrockway 5y ago
  I like structured logging but structured logging takes you away from a domain-specific language. Instead of log.Infof("fooed the bar: %v, baz=%v", msg, baz), you'd be writing log.Info("fooed the bar", zap.String("msg", msg), zap.Int("baz", baz)). The attack surface is pretty low here, even though you're doing more than just printing to a file. There is no code injection because there is no programming language going on behind the scenes. (Of course, nothing is preventing you from writing a formatting function that compiles and runs a binary built from the log message. So you aren't intrinsically safe from stupid stuff.)
- xorcist 5y ago
  Parsing java logs isn't fun. Lots of libraries do their own mini-formats, suddenly multi-line stacktraces appear.
jeffbee 5y ago
Not the whole industry. There are plenty of people using Java on the daily who never touch log4j2.
- jlmorton 5y ago
  GP's point was broader than log4j. It's that we're all building our own spaghetti using a collection of libraries and frameworks all built with their own spaghetti. By the time software gets to the SaaS end user, it's giant rope-sized spaghetti noodles knit together with spaghetti thread spun from spaghetti fibers.
  - josephg 5y ago
    Yep. As long as our capacity to build, maintain, tune and secure our systems depends on our ability to understand the entire pot of spaghetti - we're in trouble. Security is the worst because most of our systems are only secure if every single line of running code is secure. In the face of exponentially increasing system complexity, this is a race we will always inevitably lose.
silisili 5y ago
I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.' That, and Java does everything their own way. From bouncycastle crypto to db connectors to freakin JKS, it was very much NIH all the way down to an outsider. I actually worked for a time where half my job was converting JKS to PEM for customers. Java isn't all bad, but could have used much stronger and much more conservative governance.
- hvgk 5y ago
  This is one reason I like Go. It’s exactly the opposite to Java in that respect.
  - silisili 5y ago
    Agreed 100%. As a person who writes Go daily, I appreciate that they conformed to well established standards. The crypto is redone in Go which is a little scary, but the author is among the best in the business so I generally trust it.
  - staticassertion 5y ago
    Go packages its own templating language, doesn't quite scream "minimal".
    - hvgk 5y ago
      I think that’s a separate point. It does include a template language because Go is “batteries included”. You can write productive stuff without having to import any third party packages at all. Everything you need is properly supported by the core team and written to the same standard.
- bollockitis 5y ago
  To be fair, Java existed before a lot of modern standards and its primary goals were to be fully object-oriented (because every project manager was convinced that this was the best approach at the time) and cross-platform, so they kind of HAD to rewrite everything. Everything needed a Java-friendly OO interface and had to run on the JVM on a bunch of different platforms spanning everything from Solaris servers to embedded devices. In hindsight it’s easy to say that this was an overly ambitious project with vague goals but it made sense in 1995 when technology was revolutionizing everything and creating new domains and markets.
potamic 5y ago
The notion of simplicity is really lost even among really good developers. People equate heavy abstractions that provide out of the box features or one line invocations as offering something simple, but that couldn't be farther from the truth. Reusable, composable modules is the way to build complex software. In this instance, a logging module should have absolutely nothing to do with remote lookups. If you want to tie remote lookup with your logging, add a decorator module on top of your logging module that can do it. Letting this complexity leak to the other 99% of users who will never use this is just madness.

by Pxtl 5y ago

markmark 5y ago

I don't use java and have never touched log4j, but structured logs are utterly fantastic and combined with an appropriate log server are far more useful than plain text.

lmm 5y ago
Structured logging is great, but it's vital to keep them structured all the way through. Having an API where you pass a string and then something on the other side tries to parse that string back into structured data is a recipe for disaster.
throw_m239339 5y ago
There is a difference between structured log and something that interprets these logs to create shells down the stack, inside a log library... Nobody is questioning the benefits of structured logs here. The log library itself shouldn't be interpreting these logs. It's like a HTTP framework... triggering a printer, why the hell would it be doing that by default? Seems to me that Log4j is doing to many things, including things it shouldn't be concerned with, as a log library.
- markmark 5y ago
  > Nobody is questioning the benefits of structured logs here. The guy I replied to was literally saying we should only log plain text and that doing anything more complicated is "emblematic of the crisis the industry is in".
jrockway 5y ago
I like structured logging but structured logging takes you away from a domain-specific language. Instead of log.Infof("fooed the bar: %v, baz=%v", msg, baz), you'd be writing log.Info("fooed the bar", zap.String("msg", msg), zap.Int("baz", baz)). The attack surface is pretty low here, even though you're doing more than just printing to a file. There is no code injection because there is no programming language going on behind the scenes. (Of course, nothing is preventing you from writing a formatting function that compiles and runs a binary built from the log message. So you aren't intrinsically safe from stupid stuff.)
xorcist 5y ago
Parsing java logs isn't fun. Lots of libraries do their own mini-formats, suddenly multi-line stacktraces appear.

jeffbee 5y ago

Not the whole industry. There are plenty of people using Java on the daily who never touch log4j2.

jlmorton 5y ago
GP's point was broader than log4j. It's that we're all building our own spaghetti using a collection of libraries and frameworks all built with their own spaghetti. By the time software gets to the SaaS end user, it's giant rope-sized spaghetti noodles knit together with spaghetti thread spun from spaghetti fibers.
- josephg 5y ago
  Yep. As long as our capacity to build, maintain, tune and secure our systems depends on our ability to understand the entire pot of spaghetti - we're in trouble. Security is the worst because most of our systems are only secure if every single line of running code is secure. In the face of exponentially increasing system complexity, this is a race we will always inevitably lose.

silisili 5y ago

I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.' That, and Java does everything their own way. From bouncycastle crypto to db connectors to freakin JKS, it was very much NIH all the way down to an outsider. I actually worked for a time where half my job was converting JKS to PEM for customers. Java isn't all bad, but could have used much stronger and much more conservative governance.

hvgk 5y ago
This is one reason I like Go. It’s exactly the opposite to Java in that respect.
- silisili 5y ago
  Agreed 100%. As a person who writes Go daily, I appreciate that they conformed to well established standards. The crypto is redone in Go which is a little scary, but the author is among the best in the business so I generally trust it.
- staticassertion 5y ago
  Go packages its own templating language, doesn't quite scream "minimal".
  - hvgk 5y ago
    I think that’s a separate point. It does include a template language because Go is “batteries included”. You can write productive stuff without having to import any third party packages at all. Everything you need is properly supported by the core team and written to the same standard.
bollockitis 5y ago
To be fair, Java existed before a lot of modern standards and its primary goals were to be fully object-oriented (because every project manager was convinced that this was the best approach at the time) and cross-platform, so they kind of HAD to rewrite everything. Everything needed a Java-friendly OO interface and had to run on the JVM on a bunch of different platforms spanning everything from Solaris servers to embedded devices. In hindsight it’s easy to say that this was an overly ambitious project with vague goals but it made sense in 1995 when technology was revolutionizing everything and creating new domains and markets.

potamic 5y ago

The notion of simplicity is really lost even among really good developers. People equate heavy abstractions that provide out of the box features or one line invocations as offering something simple, but that couldn't be farther from the truth. Reusable, composable modules is the way to build complex software. In this instance, a logging module should have absolutely nothing to do with remote lookups. If you want to tie remote lookup with your logging, add a decorator module on top of your logging module that can do it. Letting this complexity leak to the other 99% of users who will never use this is just madness.