I'd take Go's minimalism and simplicity over dealing with the JS ecosystem any day of the week. One produces readable code and reasonably safe software, with a powerful standard library. The other is a mess of abstractions and frameworks, and the largest risk of supply chain attacks in modern IT infrastructure. At least Deno is a step in the right direction, but the ecosystem it integrates with is a dumpster fire.
As if Go wasn't full of gotchas and warts of its own, caused by not learning from decades of programming language design, and the anti-PhD cargo cult of the ecosystem.
The most recent example being the iterators design in 1.23.
I didn't claim that Go was perfect, but I disagree that it's _full_ of gotchas and warts.
Go's design is certainly influenced by the languages that came before it, but because its designers deliberately decided to remove features, not add them. These are legends in the industry after all, so it's not like they weren't aware of these things. It's a testament of skill to produce a language that is simple, user friendly and powerful at the same time, and they made the right tradeoffs to do this successfully IMO.
On the other hand, the list of warts and gotchas in JS land is neverending. The fact we're likely stuck with it forever because of the mountain of software that depends on it is deeply unsettling.
If you don’t value simplicity and choosing good abstractions, I don’t think Go will help you that much over JS.
JS’s ecosystem is very large, and a lot of it is junk (or worse). But it has very good things as well. Go’s ecosystem has good things too, but it’s not as though it has no junk.
Go or JS, you are going to have to apply good judgement to the portions of the ecosystem you adopt or you will get burned.
Comments
I'd take Go's minimalism and simplicity over dealing with the JS ecosystem any day of the week. One produces readable code and reasonably safe software, with a powerful standard library. The other is a mess of abstractions and frameworks, and the largest risk of supply chain attacks in modern IT infrastructure. At least Deno is a step in the right direction, but the ecosystem it integrates with is a dumpster fire.
As if Go wasn't full of gotchas and warts of its own, caused by not learning from decades of programming language design, and the anti-PhD cargo cult of the ecosystem.
The most recent example being the iterators design in 1.23.
I didn't claim that Go was perfect, but I disagree that it's _full_ of gotchas and warts.
Go's design is certainly influenced by the languages that came before it, but because its designers deliberately decided to remove features, not add them. These are legends in the industry after all, so it's not like they weren't aware of these things. It's a testament of skill to produce a language that is simple, user friendly and powerful at the same time, and they made the right tradeoffs to do this successfully IMO.
On the other hand, the list of warts and gotchas in JS land is neverending. The fact we're likely stuck with it forever because of the mountain of software that depends on it is deeply unsettling.
The biggest offender being "zero values should be usable" but then it doesn't work that way for a lot of built in types
The legends that failed with Plan 9, Inferno and Oberon industry adoption, before being Google employees.
Had Kubernetes and Docker not taken off, after pivoting from Java and Python to Go, and most likely we wouldn't be even talking about Go.
And now that those legends aren't even guiding the language design any longer, it is only going to get better.
If you don’t value simplicity and choosing good abstractions, I don’t think Go will help you that much over JS.
JS’s ecosystem is very large, and a lot of it is junk (or worse). But it has very good things as well. Go’s ecosystem has good things too, but it’s not as though it has no junk.
Go or JS, you are going to have to apply good judgement to the portions of the ecosystem you adopt or you will get burned.