I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineers where necessary.
My issue with pointing to this and calling it “practical” and “easy to understand” is twofold:
(1) Go implicitly makes its ease of understanding dependent on an having existing background knowledge of concepts that the HN crowd is likely to have, themselves, which biases people but isn’t particularly easy to learn on its own merits (versus, say, Python)
(2) Most companies cannot afford to solve engineering problems by throwing more bodies at it, but with Go your option is either that or leveraging external code generation
As far as “taking the time to get each piece right”, this stuff isn’t cutting edge technology development! Go isn’t doing dependent typing or borrow checking or scoped effects!
Everything that people lambast the language over not having is old hat, it’s like defending a car manufacturer who chose to use carburetors over fuel injection by saying that they’re trying to figure out how to do it right.
Counterpoint, regarding “reducing the cost of features”: Go is spreading a simplified understanding of what garbage collection performance means to a generation of programmers by providing almost no configuration over their GC settings. I’ve had people say that Go’s GC is obviously the best, without any point of reference with which to compare it.
What Go has done here is pick a reasonable set of trade-offs to make in their garbage collector, hard-code most of these settings into the runtime system, and package that into the philosophy of “configuration is bad”.
I will say Rust it isn't nearly as easy to enter as Go, that should be somewhat expected by their desired feature set. Likewise, they aren't as concerned with the cost of features as Go is.
I would somewhat agree with the GC stuff, I think having a couple more levers there with sensible defaults is probably ideal.
Tensorflow almost won the ML framework wars despite being clearly outclassed by Torch and it took until recently for Torch to overcome the Google brand name
> Go is taking the time to get each piece right and I'm glad for it.
Have you ever taken a look at the error handling in Go standard libraries? Rob Pike is constantly badly reinventing monadic error handling patterns and doing it wrong; He even admitted to this himself.
Error handling is an active topic of consideration, but I kinda like how it is now.
Have you ever maintained production Scala code? I have and it was an absolute nightmare compared to Go.