7 ms·

Unlike the author, I would actually say that Go is bad. This article illustrates my frustration with Go very well, on a meta level. Go's design consistently at

Unlike the author, I would actually say that Go is bad. This article illustrates my frustration with Go very well, on a meta level. Go's design consistently at every turn chose the simplest (one might say "dumbest", but I don't mean it entirely derogatory) way to do something. It was the simplest most obvious choice made by a very competent engineer. But it was entirely made in isolation, not by a language design expert. Go designs did not actually go out and research language design. It just went with the gut feel of the designers. But that's just it, those rules are there for a reason. It's like the rules of airplane design: Every single rule was written in blood. You toss those rules out (or don't even research them) at your own, and your user's, peril. Go's design reminds me of Brexit, and the famous "The people of this country have had enough of experts". And like with Brexit, it's easy to give a lame catch phrase, which seems convincing and makes people go "well what's the problem with that, keeping it simple?". Explaining just what the problem is with this "design by catchphrase" is illustrated by the article. It needs ~100 paragraphs (a quick error prone scan was 86 plus sample code) to explain just why these choices leads to a darkened room with rakes sprinkled all over it. And this article is just about Go channels! Go could get a 100 articles like this written about it, covering various aspects of its design. They all have the same root cause: Go's designers had enough of experts, and it takes longer to explain why something leads to bad outcomes, than to just show the catchphrase level "look at the happy path. Look at it!". I dislike Java more than I dislike Go. But at least Java was designed, and doesn't have this particular meta-problem. When Go was made we knew better than to design languages this way.

kbolino 2y ago
Go's designers were experts. They had extensive experience building programming languages and operating systems. But they were working in a bit of a vacuum. Not only were they mostly addressing the internal needs of Google, which is a write-only shop as far as the rest of the software industry is concerned, they also didn't have broad experience across many languages, and instead had deep experience with a few languages.
- emtel 2y ago
  Rob Pike was definitely not a PL expert and I don’t think he would claim to be. You can read his often-posted critique of C++ here: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 https://commandcenter.blogspot.com/2012/06/less-is-exponenti... In it, he seems to believe that the primary use of types in programming languages is to build hierarchies. He seems totally unfamiliar with ideas behind ML or haskell.
  - kbolino 2y ago
    Rob Pike is not a PL theoretician, but that doesn't make him not an expert in creating programming languages. Go was the third language he played a major part in creating (predecessors are Newsqueak and Limbo), and his pedigree before Google includes extensive experience on Unix at Bell Labs. He didn't create C but he worked directly with the people who did and he likely knows it in and out. So I stand by my "deep, not broad" observation. Ken Thompson requires no introduction, though I don't think he was involved much beyond Go's internal development. Robert Griesemer is a little more obscure, but Go wasn't his first language either.
    - thomashabets2 2y ago
      Re-reading Pike's C++ critique now, I do chuckle at things like; > Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features? C++ was basically saved by C++11. When written in 2012 it may have been seen as a reasonable though contrarian reaction, but history does not agree. It's just wrong. I'm very much NOT saying that every decision Go made was wrong. And often experts don't predict the future very well. But I do think that this gives further proof that while not a bad coder by any means, no Pike is very much not an expert in PL. Implementing ideas you had from the 1980s adding things you've learned since is not the same thing as learning lessons from the industry in that subfield.
      - kbolino 2y ago
        I would actually say even in 2012 the observation was probably wrong already, but notably Pike actually made it in the mid-aughts and was simply relaying it in 2012. However, being wrong about what was good for the future of C++ isn't really here nor there; Thompson also famously disliked C++. Designing a language that intentionally isn't like C++ does not equate to me as a rejection of expertise.
0x696C6961 2y ago
The Brexit comparison doesn't hold water — Brexit is widely viewed as a failure, yet Go continues to gain popularity year after year. If Go were truly as bad as described, developers wouldn't consistently return to it for new projects, but clearly, they do. Its simplicity isn't a rejection of expertise; it's a practical choice that's proven itself effective in real-world scenarios.
- tl 2y ago
  This is optics versus reality. Its goal was to address shortcomings in C++ and Java. It has replaced neither at Google and its own creators were surprised it competed with python, mostly on the value of having an easier build and deploy process.
  - 0x696C6961 2y ago
    Go has replaced Java and C++ in numerous other environments.
    - cyberpunk 2y ago
      We use a boatload of off the shelf go components; but i don't see it making any progress at replacing java at my bank. We are extremely happy with where java is these days...
      - pdimitar 2y ago
        Really bad example if you ask me. Banks are literally the last institutions that will make a change.
  - dilyevsky 2y ago
    > It has replaced neither Except that it did. Just because people aren’t rewriting borg and spanner in go doesn’t mean it isnt default choice for many of infra projects. And python got completely superseded by go even during my tenure
Mawr 2y ago
Your post is pure hot air. It would be helpful if you could provide concrete examples of aspects of Go that you consider badly designed and why.
- int_19h 2y ago
  The intersection of nil and interfaces is basically one giant counter-intuitive footgun. Or how append() sometimes returns a new slice and sometimes it doesn't (so if you forget to assign the result, sometimes it works and sometimes it doesn't). Which is understandable if you think about it in terms of low-level primitives, but in Go this somehow became the standard way of managing a high-level list of items. Or that whole iota thing.
  - 9rx 2y ago
    > Or that whole iota thing. What is the whole iota thing? For what it is, the iota design is really good. Languages like C and Typescript having having the exact same feature hidden in some weird special syntax look silly in comparison, not to mention that the weird syntax obscures what is happening. What Go has is much more clear to read and understand (which is why it gets so much grief where other languages with the same feature don't – there is no misunderstandings about what it is). But maybe you are implying that no language should present raw enums, rather they should be hidden behind sum types? That is not an unreasonable take, but that is not a design flaw. That is a different direction. If this is what you are thinking, it doesn't fit alongside the other two which could be more intuitive without completely changing what they are.
nvarsj 2y ago
The creators thought that having 50% of your codebase be `if (err != nil) { ... }` was a good idea. And that channels somehow make sense in a world without pattern matching or generics. So yeah, it's a bizarrely idiosyncratic language - albeit with moments of brilliance (like structural typing). I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable). Java has an amazing standard library as well - Golang doesn't even have many basic data structures implemented. And the ones it does, like heap, are absolutely awful to use. I really just view Golang nowadays as a nicer C with garbage collection, useful for building self contained portable binaries.
- thomashabets2 2y ago
  I think Java made many decisions that turned out to be bad only in retrospect. In Go we knew (well, experts knew) already that the choices were bad. Java is a child of the 90s. My full rant at https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... :-)
- cempaka 2y ago
  > I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable). This seems like a very odd/outdated criticism. 10s CMS full STW GCs are a thing of the past. There are low-latency GCs available for free in OpenJDK now with sub-millisecond pause times. Where I've seen the two runtimes compared (e.g. Coinbase used both langs in latency-sensitive exchange components) Java's has generally come out ahead.
  - nvarsj 2y ago
    Yes, probably out of date. Memory management was always the JVMs Achilles heel (either long pause times or too much memory usage). If that’s fixed in recent JDKs, awesome.
chabska 2y ago
> Go could get a 100 articles like this written about it, covering various aspects of its design Actually... https://100go.co/ https://100go.co/

kbolino 2y ago

Go's designers were experts. They had extensive experience building programming languages and operating systems. But they were working in a bit of a vacuum. Not only were they mostly addressing the internal needs of Google, which is a write-only shop as far as the rest of the software industry is concerned, they also didn't have broad experience across many languages, and instead had deep experience with a few languages.

emtel 2y ago
Rob Pike was definitely not a PL expert and I don’t think he would claim to be. You can read his often-posted critique of C++ here: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 https://commandcenter.blogspot.com/2012/06/less-is-exponenti... In it, he seems to believe that the primary use of types in programming languages is to build hierarchies. He seems totally unfamiliar with ideas behind ML or haskell.
- kbolino 2y ago
  Rob Pike is not a PL theoretician, but that doesn't make him not an expert in creating programming languages. Go was the third language he played a major part in creating (predecessors are Newsqueak and Limbo), and his pedigree before Google includes extensive experience on Unix at Bell Labs. He didn't create C but he worked directly with the people who did and he likely knows it in and out. So I stand by my "deep, not broad" observation. Ken Thompson requires no introduction, though I don't think he was involved much beyond Go's internal development. Robert Griesemer is a little more obscure, but Go wasn't his first language either.
  - thomashabets2 2y ago
    Re-reading Pike's C++ critique now, I do chuckle at things like; > Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features? C++ was basically saved by C++11. When written in 2012 it may have been seen as a reasonable though contrarian reaction, but history does not agree. It's just wrong. I'm very much NOT saying that every decision Go made was wrong. And often experts don't predict the future very well. But I do think that this gives further proof that while not a bad coder by any means, no Pike is very much not an expert in PL. Implementing ideas you had from the 1980s adding things you've learned since is not the same thing as learning lessons from the industry in that subfield.
    - kbolino 2y ago
      I would actually say even in 2012 the observation was probably wrong already, but notably Pike actually made it in the mid-aughts and was simply relaying it in 2012. However, being wrong about what was good for the future of C++ isn't really here nor there; Thompson also famously disliked C++. Designing a language that intentionally isn't like C++ does not equate to me as a rejection of expertise.

0x696C6961 2y ago

The Brexit comparison doesn't hold water — Brexit is widely viewed as a failure, yet Go continues to gain popularity year after year. If Go were truly as bad as described, developers wouldn't consistently return to it for new projects, but clearly, they do. Its simplicity isn't a rejection of expertise; it's a practical choice that's proven itself effective in real-world scenarios.

tl 2y ago
This is optics versus reality. Its goal was to address shortcomings in C++ and Java. It has replaced neither at Google and its own creators were surprised it competed with python, mostly on the value of having an easier build and deploy process.
- 0x696C6961 2y ago
  Go has replaced Java and C++ in numerous other environments.
  - cyberpunk 2y ago
    We use a boatload of off the shelf go components; but i don't see it making any progress at replacing java at my bank. We are extremely happy with where java is these days...
    - pdimitar 2y ago
      Really bad example if you ask me. Banks are literally the last institutions that will make a change.
- dilyevsky 2y ago
  > It has replaced neither Except that it did. Just because people aren’t rewriting borg and spanner in go doesn’t mean it isnt default choice for many of infra projects. And python got completely superseded by go even during my tenure

Mawr 2y ago

Your post is pure hot air. It would be helpful if you could provide concrete examples of aspects of Go that you consider badly designed and why.

int_19h 2y ago
The intersection of nil and interfaces is basically one giant counter-intuitive footgun. Or how append() sometimes returns a new slice and sometimes it doesn't (so if you forget to assign the result, sometimes it works and sometimes it doesn't). Which is understandable if you think about it in terms of low-level primitives, but in Go this somehow became the standard way of managing a high-level list of items. Or that whole iota thing.
- 9rx 2y ago
  > Or that whole iota thing. What is the whole iota thing? For what it is, the iota design is really good. Languages like C and Typescript having having the exact same feature hidden in some weird special syntax look silly in comparison, not to mention that the weird syntax obscures what is happening. What Go has is much more clear to read and understand (which is why it gets so much grief where other languages with the same feature don't – there is no misunderstandings about what it is). But maybe you are implying that no language should present raw enums, rather they should be hidden behind sum types? That is not an unreasonable take, but that is not a design flaw. That is a different direction. If this is what you are thinking, it doesn't fit alongside the other two which could be more intuitive without completely changing what they are.

nvarsj 2y ago

The creators thought that having 50% of your codebase be `if (err != nil) { ... }` was a good idea. And that channels somehow make sense in a world without pattern matching or generics. So yeah, it's a bizarrely idiosyncratic language - albeit with moments of brilliance (like structural typing). I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable). Java has an amazing standard library as well - Golang doesn't even have many basic data structures implemented. And the ones it does, like heap, are absolutely awful to use. I really just view Golang nowadays as a nicer C with garbage collection, useful for building self contained portable binaries.

thomashabets2 2y ago
I think Java made many decisions that turned out to be bad only in retrospect. In Go we knew (well, experts knew) already that the choices were bad. Java is a child of the 90s. My full rant at https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... :-)
cempaka 2y ago
> I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable). This seems like a very odd/outdated criticism. 10s CMS full STW GCs are a thing of the past. There are low-latency GCs available for free in OpenJDK now with sub-millisecond pause times. Where I've seen the two runtimes compared (e.g. Coinbase used both langs in latency-sensitive exchange components) Java's has generally come out ahead.
- nvarsj 2y ago
  Yes, probably out of date. Memory management was always the JVMs Achilles heel (either long pause times or too much memory usage). If that’s fixed in recent JDKs, awesome.

chabska 2y ago

> Go could get a 100 articles like this written about it, covering various aspects of its design Actually... https://100go.co/ https://100go.co/