5 ms·

It really is remarkable that Go has repeated all these mistakes, even with the benefit of having all of our field's history to learn from. Loop variable scopin

It really is remarkable that Go has repeated all these mistakes, even with the benefit of having all of our field's history to learn from. Loop variable scoping is not the only area where the designers of Go have failed to learn from past experience and instead opted for a design that lends itself to a more convenient implementation at the expense of exposing foot guns to the user: zero values are absolute dynamite, especially when combined with other language features like implicit zero initialisation of structs, multiple return values instead of sum types, or reflection-based magical JSON deserialization. When you have an empty string or a zero integer in Go, you can never be quite sure that the value you're holding is supposed to be what it is, rather than being an implicit zero value that snuck in at some point in place of a missing value. Go also fails to offer any facilities to aid programmers in writing safe and correct concurrent code, beyond some fundamentally superficial language features like syntax extensions for channel types and spawning tasks. Channels are difficult to use correctly, usually having to be used in conjunction with some other synchronisation primitive like a WaitGroup, and compose poorly with implicit zero values resulting in the need to define semantics for fundamentally nonsense operations [1]. The language offers no facilities for restricting mutation, indeed in this respect, it's even worse than C. It's too easy to write buggy, racy code in Go. There's no denying Go's initial allure, but in reality it fails to address in any systemic way the problems that have plagued the software development practice for decades. While other languages offer facilities for eliminating entire classes of bugs, all Go has to offer is an attitude that says "simply don't make mistakes." The whole language is a bitterly disappointing pile of missed opportunities. In the words of fasterthanlime, it's the billion dollar mistake all over again. [1]: https://dave.cheney.net/2014/03/19/channel-axioms https://dave.cheney.net/2014/03/19/channel-axioms

philosopher1234 3y ago
This is a very one sided view. It reads like you have not familiarized yourself much with the internal reasoning behind these decisions. You can disagree with the balance that has been struck, but you don't appear to be aware of any balancing at all.
zbobet2012 3y ago
> There's no denying Go's initial allure, but in reality it fails to address in any systemic way the problems that have plagued the software development practice for decade I find comments like this illustrate perfectly the gap between these focused on language theoretics, and those focused on building software. Go is successful because it strikes a strong balance between what practical software engineering organizations need from a language, of which safety is only one constraint. Languages also need to be: * Easy "enough" to learn * Easy to read * Easy to write * Performant * Compile quickly * Have strong tooling * Have a strong standard library * Provide good solutions for it's problem domains * Support large code bases with many dependents ... * And be "safe* Easy here is also influenced by what people already know, syntax and basic working methods need to be familiar to the vast majority of software engineers. Go is successful because for many engineers it provides enough of all of the above with *enough" safety. P.s. complex, difficult to understand languages incur more bugs then simple ones, even with additional safety. PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject...
- haileys 3y ago
  I would suggest dialling the condescension down a bit mate. There are many successful modern industrial languages out there that don't repeat the kinds of mistakes Go does. Kotlin is a strong example. So does the popularity of TypeScript show that we can successfully and fruitfully apply innovations from modern theory to industrial practise. There's a tonne of real software being built in both of those languages. You don't need to ignore decades of research to build a successful and productive language.
  - AnimalMuppet 3y ago
    You wrote the post you wrote. And then you accuse zbobet2012 of condescension? Physician, heal thyself. Don't be so condescending to assume that Go's designers ignored decades of PL research. They knew it far better than you do. And don't be condescending to the programmers, either. They aren't sheep who are led astray by shininess and PR. If that many programmers are using Go, then many of them find genuine value in Go. It solves enough actual problems well enough for it to get used, a lot.
throwaway894345 3y ago
> There's no denying Go's initial allure, but in reality it fails to address in any systemic way the problems that have plagued the software development practice for decades. Eh, loop variable scoping has bitten me a single digit number of times in the eleven years I’ve been using it. Zero values are definitely more frustrating. Lack of Rust-like enums is another pain point. But these are relatively minor compared to what Go gets right that other languages don’t—I would happily jump ship from Go the very moment something arrives that outperforms it for my use cases, and indeed I try out every language that I hear better-than-Go hype about. So far Rust wins at systems programming, but even with the enums and lack of zero values I spend so much time fighting the language (not just the borrow checker) or implementing traits, etc—far more than I spend debugging nil pointers and such in Go. And frankly Rust is the only thing I’ve found that comes close. Go is just an extremely productive language even if it has a few sharp edges (after all, people still write really important code in C, C++, or even fully dynamic languages—compare that with zero values!).
- sapling-ginger 3y ago
  > Eh, loop variable scoping has bitten me a single digit number of times in the eleven years I’ve been using it. Go ahead and ask them to remove this from the Frequently Asked Question section then. https://go.dev/doc/faq#closures_and_goroutines https://go.dev/doc/faq#closures_and_goroutines
  - throwaway894345 3y ago
    Its presence in the FAQ indicates that a lot of people have run into it, not that people commonly repeat the mistake. What exactly do you think we're debating here?

philosopher1234 3y ago

This is a very one sided view. It reads like you have not familiarized yourself much with the internal reasoning behind these decisions. You can disagree with the balance that has been struck, but you don't appear to be aware of any balancing at all.

zbobet2012 3y ago

> There's no denying Go's initial allure, but in reality it fails to address in any systemic way the problems that have plagued the software development practice for decade I find comments like this illustrate perfectly the gap between these focused on language theoretics, and those focused on building software. Go is successful because it strikes a strong balance between what practical software engineering organizations need from a language, of which safety is only one constraint. Languages also need to be: * Easy "enough" to learn * Easy to read * Easy to write * Performant * Compile quickly * Have strong tooling * Have a strong standard library * Provide good solutions for it's problem domains * Support large code bases with many dependents ... * And be "safe* Easy here is also influenced by what people already know, syntax and basic working methods need to be familiar to the vast majority of software engineers. Go is successful because for many engineers it provides enough of all of the above with *enough" safety. P.s. complex, difficult to understand languages incur more bugs then simple ones, even with additional safety. PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject...

haileys 3y ago
I would suggest dialling the condescension down a bit mate. There are many successful modern industrial languages out there that don't repeat the kinds of mistakes Go does. Kotlin is a strong example. So does the popularity of TypeScript show that we can successfully and fruitfully apply innovations from modern theory to industrial practise. There's a tonne of real software being built in both of those languages. You don't need to ignore decades of research to build a successful and productive language.
- AnimalMuppet 3y ago
  You wrote the post you wrote. And then you accuse zbobet2012 of condescension? Physician, heal thyself. Don't be so condescending to assume that Go's designers ignored decades of PL research. They knew it far better than you do. And don't be condescending to the programmers, either. They aren't sheep who are led astray by shininess and PR. If that many programmers are using Go, then many of them find genuine value in Go. It solves enough actual problems well enough for it to get used, a lot.

throwaway894345 3y ago

> There's no denying Go's initial allure, but in reality it fails to address in any systemic way the problems that have plagued the software development practice for decades. Eh, loop variable scoping has bitten me a single digit number of times in the eleven years I’ve been using it. Zero values are definitely more frustrating. Lack of Rust-like enums is another pain point. But these are relatively minor compared to what Go gets right that other languages don’t—I would happily jump ship from Go the very moment something arrives that outperforms it for my use cases, and indeed I try out every language that I hear better-than-Go hype about. So far Rust wins at systems programming, but even with the enums and lack of zero values I spend so much time fighting the language (not just the borrow checker) or implementing traits, etc—far more than I spend debugging nil pointers and such in Go. And frankly Rust is the only thing I’ve found that comes close. Go is just an extremely productive language even if it has a few sharp edges (after all, people still write really important code in C, C++, or even fully dynamic languages—compare that with zero values!).

sapling-ginger 3y ago
> Eh, loop variable scoping has bitten me a single digit number of times in the eleven years I’ve been using it. Go ahead and ask them to remove this from the Frequently Asked Question section then. https://go.dev/doc/faq#closures_and_goroutines https://go.dev/doc/faq#closures_and_goroutines
- throwaway894345 3y ago
  Its presence in the FAQ indicates that a lot of people have run into it, not that people commonly repeat the mistake. What exactly do you think we're debating here?