2 ms·

How is this damning, exactly? It's a very specific set of library quirks that are kind of expected -- Chmod doesn't do much on Windows. Arguably, maybe Chmod

How is this damning, exactly? It's a very specific set of library quirks that are kind of expected -- Chmod doesn't do much on Windows. Arguably, maybe Chmod shouldn't be in the core library if it can't do everything on every OS/architecture combination, but I am not sure that damns the language. It does the best it can, but doesn't deliver a POSIX overlay for Windows. (The complaint continues into a discussion of build tags, to make Windows-only code compile only on Windows. Again, what's the alternative here? If you want your program to do different stuff depending on the platform, there's going to be some sort of conditional to apply that.) There is then a discussion about monotonic time. The author immediately knows they want monotonic time, but there is no method that specifically returns that. Instead, go embeds the wall clock and monotonic time into a time.Time when you create one with time.Now. It uses the wall clock time for display, and monotonic time to compute the difference between two timestamps. This is not what the author expected, but it ultimately allows them to do what they want. (There is then a complaint about how when you boot a Raspberry Pi without giving userspace any time to start up, the time is set incorrectly, and Go doesn't help. Well... yeah. You can add a hardware RTC if you want the time to be correct as soon as the i2c subsystem comes up, or you can wait for NTP, or you can live with the wrong time. Not sure how any of this involves Go -- it does expect the OS to do OS things for it.) If you were going to write a damning critique of why to never use Go, it would probably be something like "this dumb library uses channels, sync.Mutex, and atomic.AddInt64 all in the same code and it deadlocks and runs out of memory" or "I installed the most popular ORM on Github and it prints colored text to the console when there is a database error rather than returning an error from the function". I think the linked article totally misses the mark on what problems people are likely to encounter with Go. Let's be honest -- 99% of programmers have no idea that their OS has a monotonic clock, and are quite surprised (and have no idea how to fix it) when start := time.Now(); time.Sleep(time.Second); fmt.Println(time.Since(start)) prints a negative number. But... with Go they don't have that problem. Pretty interesting.

jrockway 6y ago
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.

jrockway 6y ago

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.