5 ms·

> 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 practic

by 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.
amluto 3y ago
> Languages also need to be: > * Easy to read The motivating examples of this whole proposal are examples where one reads the code and the semantics are unclear. > PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject... The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do.
- josephcsible 3y ago
  > The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do. The point is that with real sum types, the compiler will enforce that you return exactly one of a value or an error, whereas in Go, you're just supposed to do so, and it's possible to write code that mistakenly returns both or neither.
- zbobet2012 3y ago
  Yeah, but multiple returns are _used for other things_. So they encompass error returns _and other things_. Multiple returns by the way would be product types that are being automatically unpacked. One of Go's core missions is to keep the number of concepts users need low. Multiple returns encompass the error use case and others.
  - amluto 3y ago
    Sure, and everything people do with sum types can also be done with plain C structs, and has been done like that in decades. But I think that saying that multiple returns (which are a sort of product type) “encompass” the error use case (logically a sum type) is overstating the case a bit. I would accept that returning errors can be achieved without sum types (and obviously is achieved without sum types in practice in the huge amount of code in languages that don’t have sum types). But I would not personally design a new language without sum types or some other similarly strict solution for the kind of programming that will encounter errors.
TheDong 3y ago
> P.s. complex, difficult to understand languages incur more bugs then simple ones, even with additional safety. Do you have any info on this? My understanding of this has been that some types of complexity make code worse, and other types make code better. For example, ruby's metaprogramming has been a source of bugs because of it's complexity. On the other hand, haskell is "complex and difficult" in terms of having a powerful type system. In my personal experience, I've found that haskell code has far fewer bugs than go code, and a large fraction of the bugs I encounter in go would not have been written in haskell or rust, in a language with a more powerful type system. Do you have any info on this link between "complexity" and bugs? > Go is successful [...] That's unrelated to whether it has systematic problems. As is much of your post to be honest. Like, yeah, javascript is successful. Bash is successful. No one will argue that those languages don't have systematic problems. The parent poster wasn't saying no one uses go, but that people use go despite its systematic problems, and tbh your comment mostly doesn't argue against that thesis, just arguing that it's successful. Which sure, yes, it is, that's not really related to the parent comment's claim that it's a poorly designed language.
- zbobet2012 3y ago
  > Do you have any info on this? There have been some studies, and while all methodologies have tradeoff's go and clojure sit near the bottom of this list in bugs/committ: https://arxiv.org/pdf/1901.10220.pdf https://arxiv.org/pdf/1901.10220.pdf Which is fascinating because they are very different languages whose unifying theme is simplicity. But this actually fits well if you know another important fact: bugs occur along organizational lines. https://augustl.com/blog/2019/best_bug_predictor_is_organizational_complexity/ https://augustl.com/blog/2019/best_bug_predictor_is_organiza... If you've been around long enough, you realize a lot, if not most bugs, come from not understanding someone else's code. Type systems arn't going to help you, when you don't understand what the code they are "protecting" is doing. > The parent poster wasn't saying no one uses go, but that people use go despite its systematic problems, and tbh your comment mostly doesn't argue against that thesis, just arguing that it's successful But if go has so many problems why do people use it? Javascript, bash, and go have a unifying trait. They are useful, they solve a problem. But unlike javascript and bash, go wasn't and isn't integrated anywhere. No ecosystem forced people into go. They choose it, writ large. Why? Well because languages are more than there type systems.
throwawaymaths 3y ago
> 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. This is a laughable claim when you've seen other languages (which have resulted in billion dollar companies with low engineering burden) that have done much better than go at this. Go is successful for other reasons, mainly it plays into the biases of certain class of developers and managers.
- tsimionescu 3y ago
  > Go is successful for other reasons, mainly it plays into the biases of certain class of developers and managers. While there is definitely an element of that, I think the main reason Go is successful are completely unrelated to the language itself. The main advantage of Go is that it is the one GC language with a slim runtime. Go programs are tiny compared to Java, C#, Python, Haskell etc. They start instantly. And they do so even if they are implementing an HTTP server or other non-trivial things. So Go is excellent at something like containerized microservices, where you want to easily run dozens of containers on a single host, and rely on quick restarts for the occasional bug.
  - throwawaymaths 3y ago
    "The main advantage of Go is that it is the one GC language with a slim runtime" I have worked in places (only startups, no big tech) that deployed go (okay, low n=2) and this was not a consideration.

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.

amluto 3y ago

> Languages also need to be: > * Easy to read The motivating examples of this whole proposal are examples where one reads the code and the semantics are unclear. > PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject... The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do.

josephcsible 3y ago
> The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do. The point is that with real sum types, the compiler will enforce that you return exactly one of a value or an error, whereas in Go, you're just supposed to do so, and it's possible to write code that mistakenly returns both or neither.
zbobet2012 3y ago
Yeah, but multiple returns are _used for other things_. So they encompass error returns _and other things_. Multiple returns by the way would be product types that are being automatically unpacked. One of Go's core missions is to keep the number of concepts users need low. Multiple returns encompass the error use case and others.
- amluto 3y ago
  Sure, and everything people do with sum types can also be done with plain C structs, and has been done like that in decades. But I think that saying that multiple returns (which are a sort of product type) “encompass” the error use case (logically a sum type) is overstating the case a bit. I would accept that returning errors can be achieved without sum types (and obviously is achieved without sum types in practice in the huge amount of code in languages that don’t have sum types). But I would not personally design a new language without sum types or some other similarly strict solution for the kind of programming that will encounter errors.

TheDong 3y ago

> P.s. complex, difficult to understand languages incur more bugs then simple ones, even with additional safety. Do you have any info on this? My understanding of this has been that some types of complexity make code worse, and other types make code better. For example, ruby's metaprogramming has been a source of bugs because of it's complexity. On the other hand, haskell is "complex and difficult" in terms of having a powerful type system. In my personal experience, I've found that haskell code has far fewer bugs than go code, and a large fraction of the bugs I encounter in go would not have been written in haskell or rust, in a language with a more powerful type system. Do you have any info on this link between "complexity" and bugs? > Go is successful [...] That's unrelated to whether it has systematic problems. As is much of your post to be honest. Like, yeah, javascript is successful. Bash is successful. No one will argue that those languages don't have systematic problems. The parent poster wasn't saying no one uses go, but that people use go despite its systematic problems, and tbh your comment mostly doesn't argue against that thesis, just arguing that it's successful. Which sure, yes, it is, that's not really related to the parent comment's claim that it's a poorly designed language.

zbobet2012 3y ago
> Do you have any info on this? There have been some studies, and while all methodologies have tradeoff's go and clojure sit near the bottom of this list in bugs/committ: https://arxiv.org/pdf/1901.10220.pdf https://arxiv.org/pdf/1901.10220.pdf Which is fascinating because they are very different languages whose unifying theme is simplicity. But this actually fits well if you know another important fact: bugs occur along organizational lines. https://augustl.com/blog/2019/best_bug_predictor_is_organizational_complexity/ https://augustl.com/blog/2019/best_bug_predictor_is_organiza... If you've been around long enough, you realize a lot, if not most bugs, come from not understanding someone else's code. Type systems arn't going to help you, when you don't understand what the code they are "protecting" is doing. > The parent poster wasn't saying no one uses go, but that people use go despite its systematic problems, and tbh your comment mostly doesn't argue against that thesis, just arguing that it's successful But if go has so many problems why do people use it? Javascript, bash, and go have a unifying trait. They are useful, they solve a problem. But unlike javascript and bash, go wasn't and isn't integrated anywhere. No ecosystem forced people into go. They choose it, writ large. Why? Well because languages are more than there type systems.

throwawaymaths 3y ago

> 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. This is a laughable claim when you've seen other languages (which have resulted in billion dollar companies with low engineering burden) that have done much better than go at this. Go is successful for other reasons, mainly it plays into the biases of certain class of developers and managers.

tsimionescu 3y ago
> Go is successful for other reasons, mainly it plays into the biases of certain class of developers and managers. While there is definitely an element of that, I think the main reason Go is successful are completely unrelated to the language itself. The main advantage of Go is that it is the one GC language with a slim runtime. Go programs are tiny compared to Java, C#, Python, Haskell etc. They start instantly. And they do so even if they are implementing an HTTP server or other non-trivial things. So Go is excellent at something like containerized microservices, where you want to easily run dozens of containers on a single host, and rely on quick restarts for the occasional bug.
- throwawaymaths 3y ago
  "The main advantage of Go is that it is the one GC language with a slim runtime" I have worked in places (only startups, no big tech) that deployed go (okay, low n=2) and this was not a consideration.