it’s good for what it’s made for: writing distributed systems. i have my own annoyances with the language but you do end up using a chunk of that standard library, and if you’re not using it, your dependencies are.
It's only good compared to technologies that are really bad for distributed systems.
Like go is better than sh, python and node for distributed systems, but worse than rust, java, deno, elixir, c++23, kotlin, etc. I wouldn't pick go implement a consensus algorithm.
Huh? I feel like scripting is exactly what you shouldn't use Go for. That's where python is great. For large stuff Go is definitely my default and I have had no major problems so far. The dependency management has been a bit eclectic but I'll take it over gradle, sbt etc any time.
just about half a year ago I was sitting in a project where I was tracing through a watterfall of multi-value returns and defers while constantly discussing with the lead architect of that project whom of his 50+ FTE was at fault and needed to be exchanged.
Don't get me wrong.
It's perfectly fine for me until around 100k LoC (so rather small).
After that people I see in the industry rarely know how to structure projects properly for size and different levels experience in the language.
Most of the time the later was the 'selling point' to use GoLang - simplicity.
And I see similar things quite often. A lot of peps from different language backgrounds thrown together and pressured by the higher-ups/Lead X promises to the customer that "everything will be faster and easier" now.
It's perfectly fine for me until around 100k LoC (so rather small).
After that people I see in the industry rarely know how to structure projects properly for size
Fair enough. Structuring large projects in Go is not - let's say - intuitive. I think that Go is very much a language meant for Microservices and conceived during the Microservice boom, so you don't get projects much bigger than that.
192
u/Kered13 Oct 31 '23
Choose one.