I guess I ignored the section on resolving the long dependency graph, and that's important to discuss. The community could do a better job of splitting their clients and servers into separate modules (writing to InfluxDB should not require downloading the code for an InfluxDB server). (I do love using servers written in Go, though, because my integration tests can just start one up at the beginning of the test and talk to it. No setup/teardown required outside of "go test"; no extra dependencies to make developers install. It's nice!)
The language could do a better job of letting you choose "plugins" at runtime; if you use Prometheus for monitoring and not InfluxDB, it's not ideal to have a bunch of 'if UseInfluxDB { send to InfluxDB }' compiled into your binary. The alternative is to dlopen something that provides monitoring functionality; been there done that with Nginx and OpenTracing, and it's hugely painful. (There simply aren't binaries that work together; you can't wget a prebuilt plugin into your Nginx docker image. You have to build both from scratch.) Or, you can at least defer the monitoring library selection from library to application with an abstraction layer like OpenTelemetry. The cost to the code author is high, and it still doesn't let the operator choose the backend at runtime. Overall, this is something that a programming language should choose to take on, but it's also exceedingly difficult to get right. I haven't seen it done right, anyway; so all you have to go on is a list of ways to get it wrong.
It is annoying that there are 600 different logging libraries. But people are VERY particular about logs, and one person's treasure is another person's "that is so horrible I can't even use it". If there is a programming language where everyone uses the same logging library and that library provides structured logging, the log levels are [trace, debug, info, warning, error, fatal], has built-in support for sending to third-party services (Sentry), rate-based sampling, and metrics generation... then that sounds great to me and I'll definitely take a look. But for some reason, I kind of doubt it. People have a lot of thoughts here, and are very committed to their thoughts. In the Go world, libraries with wonderful authors let you inject your own logger, and it mostly works well. GRPC, pgx, Jaeger, etc. all do a good job here. K8s's client_go does a bad job here, but they're working on fixing it :)
Wasn't planning to get sucked into this discussion, but the article does raise some good points. I'll be very honest and say rants like this sound to me like a pre-rant for next year when it's "why I quit programming forever and became a beet farmer". To succeed at programming, you will have to endure in the face of minor problems with your tools. You will have to use those tools to program better tools, after all. And even then, it still won't be perfect, and you'll see a new set of problems to be mildly annoyed at. Such is life! Ultimately, for me, Go has supported my efforts to make stuff. I run it on STM32 microcontrollers. I run it on Beaglebones. I ran it on thousands of servers at Google. It just kind of gets out of the way and lets you turn your ideas into things that you can use. Who can complain.
The language could do a better job of letting you choose "plugins" at runtime; if you use Prometheus for monitoring and not InfluxDB, it's not ideal to have a bunch of 'if UseInfluxDB { send to InfluxDB }' compiled into your binary. The alternative is to dlopen something that provides monitoring functionality; been there done that with Nginx and OpenTracing, and it's hugely painful. (There simply aren't binaries that work together; you can't wget a prebuilt plugin into your Nginx docker image. You have to build both from scratch.) Or, you can at least defer the monitoring library selection from library to application with an abstraction layer like OpenTelemetry. The cost to the code author is high, and it still doesn't let the operator choose the backend at runtime. Overall, this is something that a programming language should choose to take on, but it's also exceedingly difficult to get right. I haven't seen it done right, anyway; so all you have to go on is a list of ways to get it wrong.
It is annoying that there are 600 different logging libraries. But people are VERY particular about logs, and one person's treasure is another person's "that is so horrible I can't even use it". If there is a programming language where everyone uses the same logging library and that library provides structured logging, the log levels are [trace, debug, info, warning, error, fatal], has built-in support for sending to third-party services (Sentry), rate-based sampling, and metrics generation... then that sounds great to me and I'll definitely take a look. But for some reason, I kind of doubt it. People have a lot of thoughts here, and are very committed to their thoughts. In the Go world, libraries with wonderful authors let you inject your own logger, and it mostly works well. GRPC, pgx, Jaeger, etc. all do a good job here. K8s's client_go does a bad job here, but they're working on fixing it :)
Wasn't planning to get sucked into this discussion, but the article does raise some good points. I'll be very honest and say rants like this sound to me like a pre-rant for next year when it's "why I quit programming forever and became a beet farmer". To succeed at programming, you will have to endure in the face of minor problems with your tools. You will have to use those tools to program better tools, after all. And even then, it still won't be perfect, and you'll see a new set of problems to be mildly annoyed at. Such is life! Ultimately, for me, Go has supported my efforts to make stuff. I run it on STM32 microcontrollers. I run it on Beaglebones. I ran it on thousands of servers at Google. It just kind of gets out of the way and lets you turn your ideas into things that you can use. Who can complain.