6 ms·

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 7

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Basically the Go community got the exchange off on the wrong foot. Personally, I sense egos were at stake. They created a language which is simple by design, but then still wanted to claim a sort of opinionated superiority for it. If they'd said, "oh go is just a simple little language we enjoy using for such and such, perhaps you will too" then people who don't like Go wouldn't have felt provoked. 1: Pun not intended.

ainar-g 5y ago
> However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal design goal.
- ______-_-______ 5y ago
  Here's the original Rob Pike quote: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. The source seems to be MSDN, but the link has bit-rotted. https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. You don't have to be a "researcher" to understand sum types or generics. There's a large part of the industry that thinks we should limit ourselves to concepts that can be understood by a beginner, and I think it's holding the industry back. I can't think of another industry where people think this way.
  - ainar-g 5y ago
    That seems like a pragmatic and honest way of looking at software engineering, consistent with Russ Cox's later thoughts on the difference between programming and software engineering[1]. It sounds to me less like “this is a language for beginners and underperformers” and more like “this is a language using which large teams of programmers with varying levels of experience can be productive together”. > This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. This is not my experience. Of the six team leads with whom I've discussed the language (after they've had some experience with it) only one was put off by it. The rest were either glad that “something simpler is finally here” or were of the opinion that Go is “just another language”. (Interestingly enough, the one person who was not impressed was a big fan of purely functional programming, while all others were C++/Java/Ruby kind of people. Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.) [1]: https://research.swtch.com/vgo-eng https://research.swtch.com/vgo-eng
    - thinkharderdev 5y ago
      As a fan of pure functional programming who very much dislikes Go, I can vouch for this statement. But in the spirit of giving credit where due one thing that the pure functional crowd can learn from Go is the value in making really good tooling and really try to genuinely make easy things easy.
    - Zababa 5y ago
      > Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.) It's not only your personal observation (though I would remove the "purely" from "purely functional languages). A good indication of that: on the Go 2020 survey, the 6 most popular responses to "Which critical language features do you need that are no available in Go?" are features that functional programming languages have. All of these features are in ML and its descendants (SML, OCaml, Haskell, Scala, etc). The graph: https://go.dev/blog/survey2020/missing_features.svg https://go.dev/blog/survey2020/missing_features.svg The article: https://go.dev/blog/survey2020-results https://go.dev/blog/survey2020-results
- gerbilly 5y ago
  Sorry can't find any since google results seem to get worse year over year. Basically I gleaned this impression from the go message groups more than 5 years ago. Go is pretty nice, but IMHO, it's no masterpiece. There's a reason we keep copying C like syntax, and it's not just familiarity. C could be criticized on many points, but in my opinion it was a brilliant case of language design: Only 30 keywords, the stdllib was a separate thing (not common at the time), great as a systems programming language. If you think of C of the 1970s as a sort of souped up macro assembler, you're not far from the truth, and it was wildly successful, also, because of what it left out. Go might have had similar ambitions, but the execution was not thought out as well. If you want to design a truly great language, it turns out it's not enough to merely leave things out. I got the sense that the Go people wanted to be taken seriously on the same level as great achievements like C and UNIX, but the creators quickly saw through the incoming critiques that they hadn't pulled this off. You know when you create something and then receive criticism? If the criticism is clearly wrong or due to a misunderstanding, you're not upset about it typically. You explain that the misunderstanding, and typically the person critiquing says, "ah ok..." and moves on. But the critiques which really get to you are usually the ones which you know deep down are right. I think maybe this is why the creators of Go seemed so touchy about it. EDIT: And for the record I program in Java and Rust mostly, a bit of Python too. I hate C++ (a sprawling mess) and also don't give a crap about Haskell or monads.
  - scns 5y ago
    > I got the sense that the Go people wanted to be taken seriously on the same level as great achievements like C and UNIX, but the creators quickly saw through the incoming critiques that they hadn't pulled this off. One of the creators of Go is Ken Thompson. "I did the first of two or three versions of UNIX all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of the operating system."
- MAGZine 5y ago
  look at most threads when people ask about quirky aspects of go, such as: a) why are there such short variable names, such that you see calls like b.c.d.Method() all of the time? b) why is there no Set type? c) why is date/time encoding/decoding inconsistent in json marshaling/unmarshaling (versus other types)?
zozbot234 5y ago
Go has a lot more in common with Alef or Limbo than it does with C, but close enough. It feels like it's been forever stuck in the early 1990s, and now that it's gotten generics it has perhaps reached the late 1990s.
philosopher1234 5y ago
I’m glad you brought this up because I agree Rob pikes quote about go being simple for average programmers has been very provocative, because it’s been interpreted as “Google devs are too stupid for a good language like Haskell, so if you use go it’s because you’re stupid too”. I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language”. With that interpretation, go is better not just for stupid programmers, but even for the smartest programmers.
- ______-_-______ 5y ago
  That line of thinking only works up to a certain point. I could say assembly language is simpler, now you don't have to think about functions or basic blocks, you can save your thinking for the problem you're trying to solve! But sometimes pushing complexity into the language instead of onto the users is the better way to go. Higher-level abstractions make things easier. I would rather spend my thought cycles on the business problem, than on reimplementing sum types, or casting interface{} everywhere, or propagating errors by hand.
  - philosopher1234 5y ago
    Certainly, whether or not go has made the right trade offs on simplicity is arguable. I’m not certain whether those features you mentioned would be worth adding to the language or not, but I do know that my experience interacting with Go code has been much easier than my experience interacting with Java code. Haskell & Rust have been fun for me to play with, but they were also harder for me to work with. Anyways, I can’t give the final word on this question, but those are my two cents.
- deleted 5y ago
  [deleted]
- tharne 5y ago
  > I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language”. I think you're being too charitable here. Rob Pike is a very smart and articulate guy. If he had wanted to say "go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language", then he would have. Instead he took a dig at google employees. Make of that what you will, but I don't think it's case of him mean anything other than exactly what he said.
mseepgood 5y ago
> Go is really s souped up version of C. But with generics, methods and interfaces, proper strings, maps etc., first-class functions, built-in concurrency, a module system, automatic memory management, a well-rounded standard library and so so so much more.
- jhgb 5y ago
  Not even that -- it's a souped-up version of Oberon with these features. (Although of course, out of those, Oberon had already had a module system and automatic memory management.)
  - mseepgood 5y ago
    That's a good thing.
    - int_19h 5y ago
      It would have been, if they made it as footgun-proof as Wirth's languages generally are.
ModernMech 5y ago
> Basically the Go community got the exchange off on the wrong foot. Indeed. Then there was that whole controversy over the naming collision with the Go! language. Basically there's an unspoken etiquette in the PL community that there should be zero name conflicts between languages, as there are enough good names out there, it really shouldn't be an issue. The Go! language had been around for a long time, and I realize it was an obscure, little known language, but that's true for 99% of languages out there. So the idea that Google can just invent a language out of the blue with the same name as yours, after you've been using the name for a decade, and then just use their size and clout to essentially destroy your language is.... well that's unsettling to people in the PL community. The way they handled the situation didn't exactly win over hearts: The naming similarity is unfortunate. However, there are many computing products and services named Go. In the 11 months since our release, there has been minimal confusion of the two languages, so we are closing this issue. Status changed to Unfortunate. https://github.com/golang/go/issues/9#issuecomment-66047478 https://github.com/golang/go/issues/9#issuecomment-66047478 Basically a sad trombone. The image of Go has never recovered in my eye.

ainar-g 5y ago

> However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal design goal.

______-_-______ 5y ago
Here's the original Rob Pike quote: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. The source seems to be MSDN, but the link has bit-rotted. https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. You don't have to be a "researcher" to understand sum types or generics. There's a large part of the industry that thinks we should limit ourselves to concepts that can be understood by a beginner, and I think it's holding the industry back. I can't think of another industry where people think this way.
- ainar-g 5y ago
  That seems like a pragmatic and honest way of looking at software engineering, consistent with Russ Cox's later thoughts on the difference between programming and software engineering[1]. It sounds to me less like “this is a language for beginners and underperformers” and more like “this is a language using which large teams of programmers with varying levels of experience can be productive together”. > This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. This is not my experience. Of the six team leads with whom I've discussed the language (after they've had some experience with it) only one was put off by it. The rest were either glad that “something simpler is finally here” or were of the opinion that Go is “just another language”. (Interestingly enough, the one person who was not impressed was a big fan of purely functional programming, while all others were C++/Java/Ruby kind of people. Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.) [1]: https://research.swtch.com/vgo-eng https://research.swtch.com/vgo-eng
  - thinkharderdev 5y ago
    As a fan of pure functional programming who very much dislikes Go, I can vouch for this statement. But in the spirit of giving credit where due one thing that the pure functional crowd can learn from Go is the value in making really good tooling and really try to genuinely make easy things easy.
  - Zababa 5y ago
    > Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.) It's not only your personal observation (though I would remove the "purely" from "purely functional languages). A good indication of that: on the Go 2020 survey, the 6 most popular responses to "Which critical language features do you need that are no available in Go?" are features that functional programming languages have. All of these features are in ML and its descendants (SML, OCaml, Haskell, Scala, etc). The graph: https://go.dev/blog/survey2020/missing_features.svg https://go.dev/blog/survey2020/missing_features.svg The article: https://go.dev/blog/survey2020-results https://go.dev/blog/survey2020-results
gerbilly 5y ago
Sorry can't find any since google results seem to get worse year over year. Basically I gleaned this impression from the go message groups more than 5 years ago. Go is pretty nice, but IMHO, it's no masterpiece. There's a reason we keep copying C like syntax, and it's not just familiarity. C could be criticized on many points, but in my opinion it was a brilliant case of language design: Only 30 keywords, the stdllib was a separate thing (not common at the time), great as a systems programming language. If you think of C of the 1970s as a sort of souped up macro assembler, you're not far from the truth, and it was wildly successful, also, because of what it left out. Go might have had similar ambitions, but the execution was not thought out as well. If you want to design a truly great language, it turns out it's not enough to merely leave things out. I got the sense that the Go people wanted to be taken seriously on the same level as great achievements like C and UNIX, but the creators quickly saw through the incoming critiques that they hadn't pulled this off. You know when you create something and then receive criticism? If the criticism is clearly wrong or due to a misunderstanding, you're not upset about it typically. You explain that the misunderstanding, and typically the person critiquing says, "ah ok..." and moves on. But the critiques which really get to you are usually the ones which you know deep down are right. I think maybe this is why the creators of Go seemed so touchy about it. EDIT: And for the record I program in Java and Rust mostly, a bit of Python too. I hate C++ (a sprawling mess) and also don't give a crap about Haskell or monads.
- scns 5y ago
  > I got the sense that the Go people wanted to be taken seriously on the same level as great achievements like C and UNIX, but the creators quickly saw through the incoming critiques that they hadn't pulled this off. One of the creators of Go is Ken Thompson. "I did the first of two or three versions of UNIX all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of the operating system."
MAGZine 5y ago
look at most threads when people ask about quirky aspects of go, such as: a) why are there such short variable names, such that you see calls like b.c.d.Method() all of the time? b) why is there no Set type? c) why is date/time encoding/decoding inconsistent in json marshaling/unmarshaling (versus other types)?

zozbot234 5y ago

Go has a lot more in common with Alef or Limbo than it does with C, but close enough. It feels like it's been forever stuck in the early 1990s, and now that it's gotten generics it has perhaps reached the late 1990s.

philosopher1234 5y ago

I’m glad you brought this up because I agree Rob pikes quote about go being simple for average programmers has been very provocative, because it’s been interpreted as “Google devs are too stupid for a good language like Haskell, so if you use go it’s because you’re stupid too”. I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language”. With that interpretation, go is better not just for stupid programmers, but even for the smartest programmers.

______-_-______ 5y ago
That line of thinking only works up to a certain point. I could say assembly language is simpler, now you don't have to think about functions or basic blocks, you can save your thinking for the problem you're trying to solve! But sometimes pushing complexity into the language instead of onto the users is the better way to go. Higher-level abstractions make things easier. I would rather spend my thought cycles on the business problem, than on reimplementing sum types, or casting interface{} everywhere, or propagating errors by hand.
- philosopher1234 5y ago
  Certainly, whether or not go has made the right trade offs on simplicity is arguable. I’m not certain whether those features you mentioned would be worth adding to the language or not, but I do know that my experience interacting with Go code has been much easier than my experience interacting with Java code. Haskell & Rust have been fun for me to play with, but they were also harder for me to work with. Anyways, I can’t give the final word on this question, but those are my two cents.
deleted 5y ago
[deleted]
tharne 5y ago
> I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language”. I think you're being too charitable here. Rob Pike is a very smart and articulate guy. If he had wanted to say "go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language", then he would have. Instead he took a dig at google employees. Make of that what you will, but I don't think it's case of him mean anything other than exactly what he said.

mseepgood 5y ago

> Go is really s souped up version of C. But with generics, methods and interfaces, proper strings, maps etc., first-class functions, built-in concurrency, a module system, automatic memory management, a well-rounded standard library and so so so much more.

jhgb 5y ago
Not even that -- it's a souped-up version of Oberon with these features. (Although of course, out of those, Oberon had already had a module system and automatic memory management.)
- mseepgood 5y ago
  That's a good thing.
  - int_19h 5y ago
    It would have been, if they made it as footgun-proof as Wirth's languages generally are.

ModernMech 5y ago

> Basically the Go community got the exchange off on the wrong foot. Indeed. Then there was that whole controversy over the naming collision with the Go! language. Basically there's an unspoken etiquette in the PL community that there should be zero name conflicts between languages, as there are enough good names out there, it really shouldn't be an issue. The Go! language had been around for a long time, and I realize it was an obscure, little known language, but that's true for 99% of languages out there. So the idea that Google can just invent a language out of the blue with the same name as yours, after you've been using the name for a decade, and then just use their size and clout to essentially destroy your language is.... well that's unsettling to people in the PL community. The way they handled the situation didn't exactly win over hearts: The naming similarity is unfortunate. However, there are many computing products and services named Go. In the 11 months since our release, there has been minimal confusion of the two languages, so we are closing this issue. Status changed to Unfortunate. https://github.com/golang/go/issues/9#issuecomment-66047478 https://github.com/golang/go/issues/9#issuecomment-66047478 Basically a sad trombone. The image of Go has never recovered in my eye.