8 ms·

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So

by mabbo 6y ago

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?

the_af 6y ago
I know a case (second hand) where they migrated from a Java backend to Go, then had to roll it all back to Java because it was too hard and error prone to maintain. This is a very successful business, not a startup. No idea why they felt they had to migrate to Go in the first place. I'd rather not mention the company, even though I did not work there.
- thebean11 6y ago
  Yeesh, I can't imagine migrating a large backend codebase from any language to any language. And we're talking about migrating from Java..which is extremely well supported and probably the easiest language to hire for..
- nine_k 6y ago
  Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.
  - Groxx 6y ago
    It makes it easier to start concurrent stuff, but without ready-to-use type-safe abstractions like Java provides I'd say it's far harder to make correct concurrent stuff in Go. And while the race detector is wonderful, especially since it's baked in, it's nowhere near sufficient.
  - apta 6y ago
    I disagree. There is so much boilerplate involved with managing concurrency in golang compared to Java. It's very error prone in practice and difficult to extend and manage. golang has nothing remotely close to `java.util.concurrent`.
- kjksf 6y ago
  And as a counterpoint there are many non-hearsay examples where teams migrated large projects from C++/Java/Python/Ruby/JavaScript to Go. Described publicly like Dropbox's backend migration to Go: https://twitter.com/jamwt/status/629727590782099456 https://twitter.com/jamwt/status/629727590782099456 I could give you tens examples of that, many have been posted on HN.
  - the_af 6y ago
    No need to counterpoint my example. The original list of case studies already lists Go's success stories. I was just providing the example the parent post was asking about. And note it's "hearsay" to you only because I didn't name the company and people involved -- because I was told this in confidence -- but this is a major company where I'm from, and their attempt at adopting Go ended up in disaster. Just a data point, that's all.
networkimprov 6y ago
Discord abandoned Go due to GC overhead. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- naikrovek 6y ago
  This is a puzzling decision on Discord's part, because they found the single line of code causing their problem and they didn't think to change that line of code for their own needs. Go distributions include the source for Go itself, so building your own Go binary with your own changes incorporated is dead easy. And, the change they needed is a single-line change, which means it's easy to bring that change forward as new versions of Go are released. Discord: haha, no, that's silly! let's spend 100,000x more effort and rewrite it all in another language! Now, before those of you who learned to argue on the internet extrapolate what I wrote and imagine that I wrote words I didn't write: I'm not saying that Go should never be abandoned for another language. I'm saying that this particular example of this particular choice puzzles me, because of the reasons stated, and ONLY the reasons stated.
  - dilyevsky 6y ago
    Not to mention they could’ve probably just updated their old go runtime...
    - aw1621107 6y ago
      IIRC none of the available Go releases at the time the decision to switch to Rust was made (<=1.10, I think?) addressed their particular issue, and by the time a Go release did fix their issue (1.12?) they were pretty far along with their rewrite. Not entirely sure that I have the Go versions right, but that's what I remembered off the top of my head.
      - aw1621107 6y ago
        Just found a comment by a Discord engineer that says that they did try upgrading their Go runtime (presumably when the decision to rewrite was made) [0]: > Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect. [0]: https://old.reddit.com/r/programming/comments/eyuebc/why_discord_is_switching_from_go_to_rust/fgk56y4/ https://old.reddit.com/r/programming/comments/eyuebc/why_dis...
zerr 6y ago
Go is officially banned by Google for Fuchsia: https://fuchsia.dev/fuchsia-src/contribute/governance/policy/programming_languages https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
- kyrra 6y ago
  There was discussion about this 6 months ago, such as this comment. https://news.ycombinator.com/item?id=22412475 https://news.ycombinator.com/item?id=22412475
- Laremere 6y ago
  "Banned", while technically accurate, gives the wrong connotation. More precisely, it wasn't selected as one of the languages for the project. That is, Fuchsia has a set of technical challenges, and it is a reasonable engineering practice to select a minimal set of languages to tackle those challenges. Go's doesn't have a unique niche or a dominate strength in an important area when it comes to Fuchsia, so they're not using it. (As I understand that having read your link previously.)
tptacek 6y ago
Case studies like these are always selected because they’re positive; you don’t have to wonder about the biases. Someone else might want to collect the negative cases; Discord, for instance, and their fights with the GC.
- typical182 6y ago
  I had looked at the Discord GC blog issue [1] fairly carefully, and it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Also, after publishing that blog, they also said they had wanted to try Rust for other reasons: wanted to try out rust as well for services like this, due to adoption elsewhere in the company. Also, after upgrading between 4 golang versions on this service and noticing it didn't materially change performance, we decided to just spend our time on the rewrite (for fun, and latency) and to get a head start into the asynchronous rust ecosystem. [2] And nothing wrong with that decision from my point of view (Rust is great!), but I believe they could have solved it without dropping Go for that particular service that they blogged about, at least as far as I was able to understand. [1] https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to... [2] https://news.ycombinator.com/item?id=22239707 https://news.ycombinator.com/item?id=22239707
  - tptacek 6y ago
    I don't think anyone read that case study as somehow disqualifying for Go, so there's no need to litigate it; it's an example of a "Go -> Something Else" case study, that's all.
    - typical182 6y ago
      True, and it was an interesting case study.
  - aw1621107 6y ago
    > it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Do you know if that was the case when the decision to switch was made? They said elsewhere they tried Go 1.7-1.10 and none of those solved their issue, and at least back when the blog post was released I couldn't figure out whether the fix for the corresponding issue was known to have been slated for release in the next Go release.
candiddevmike 6y ago
Anything that has to do with UI in my opinion. Go's lack of classes (factories, inheritance, etc) and verbosity make graphical layouts very, very tedious.
- throwaway894345 6y ago
  I think this is only true for OOP-style "widget-based" UI toolkits. I've had a very good time writing console UIs using a reactive style; obviously console UIs are simpler, but I think when people want inheritance in UIs, it's for things like 2D layout (in typical OOP toolkits, every widget type is derived from some base Widget class that does layout things) which are also present in console UIs. I would be interested to hear rebuttals or other thoughts.
  - athrun 6y ago
    Can I ask which reactive-style console UI library you have been enjoying using? Or was it a custom thing you made from scratch?
    - throwaway894345 6y ago
      Custom, made from scratch probably 5 years ago just for fun.
cmrdporcupine 6y ago
Let me just say that I've been at Google for almost 9 years, and have recently started looking for work elsewhere and it seems that Go is far more popular outside of Google than inside it. Which disappoints me because my experiences with the language internally have biased me such that I have no desire to go use it elsewhere. I've said this before, but I think it's a bit dishonest to sell this as a "Google language." It is an accepted language here, along with Python, Java, JS/TS, Dart, and C++. But it is by no means dominant. To put it another way, it seems if the goal is to avoid working in Go I am better off staying @ Google than leaving. And that's weird, and maybe revealing.
- tomlu 6y ago
  My current and last positions both involve(d) writing (mostly) Go code, so it's definitely possible to find Go jobs within Google.
  - apta 6y ago
    OP wants to avoid using golang, not to find a job where he can use it.
- Ericson2314 6y ago
  If you look at the way the rest of the industry cargo-cults Google, Go almost looks like a false flag attack to increase Google's competitive advantage while the cargo-cults drown in boilerplate and an inability to abstract.
- philosopher1234 6y ago
  This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.
  - cmrdporcupine 6y ago
    Other people have touched on that and I've opined on it in the past, I don't think this is the thread for that. I think you'll find HN is a divided community on golang. Myself I find the language... kind of insulting... in its lack of basic modern constructs. I find its emerging prevalence to be a concerning trend, and I think it's going to lead to a lot of brittle, boilerplate code. Obviously others disagree. I'll leave it at that.
karmakaze 6y ago
I did run into one Go codebase that was closures all the way down. Due to limited abstractions, closures were created and passed around and returned everywhere through so many layers with arbitrary generic naming. It was the worst. At one point I wondered if it was a ploy to ensure employment but I don't think it was.
cpuguy83 6y ago
Honestly any low level/system code is pretty disastrous in Go. Edit: Just to add to that statement: the work stealing goroutine runtime is particularly problematic, certain things are even impossible in go due to it. If you look at runc, large parts of it are written in C and called during init before the runtime is started.
- apta 6y ago
  Even higher level programs are quite terrible in golang. It seems it's only good for small (usually networked) tools that can perhaps make use of concurrency.
mrkurt 6y ago
We tried to build a JS runtime in Go and it was a disaster. .NET was actually a better choice, though we ultimately went with Rust (and ultimately, ultimately went with Deno ... which also started as Go).
apta 6y ago
In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend to more verbose and error prone code. Monitoring is poor compared to the JVM/.NET, and performance is worse in general. It has very questionable, if not outright bad design decisions (e.g. they wanted to save on keywords so they don't have public/private, so changing the visibility of a variable or function now results in a huge diff if it's used in many places). The list is too long to elaborate on in a few paragraphs.
- cpuguy83 6y ago
  > so changing the visibility of a variable or function now results in a huge diff if it's used in many places) You can create an exported version of the function (calling into the unexported one), no diff except the new function. But also just updating all the callsights is usually not a huge issue, especially if you are using an IDE such as GoLand.
  - apta 6y ago
    > You can create an exported version of the function These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims. I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction
    - cpuguy83 6y ago
      I don't agree with the term "hack" here. Different is not "hack". I maintain some very large codebases. This has never been an issue. If one decides to export a function, the only callers of that function will be from within the package it was defined in already. Even within a package, how many call sites will there actually be and do they need to use the exported version of the function? I'm not saying it's good, or bad, just that in my (fairly extensive) experience it has not been a problem. I do recognize that some people may have problems with it, though.
Inufu 6y ago
I built (at Google) a prototype system in Go, then rewrote complete in C++: - Go was too slow and GC too much overhead (real time analytics) - Error handling and propagation is insanely verbose in Go, the C++ actually was more concise - lack of generics made it impossible to reuse complex high-performance data structures and algorithms even within the project Haven't looked back and between C++, Rust, Swift and Python, I'd never choose to use Go again.

by mabbo 6y ago

the_af 6y ago

I know a case (second hand) where they migrated from a Java backend to Go, then had to roll it all back to Java because it was too hard and error prone to maintain. This is a very successful business, not a startup. No idea why they felt they had to migrate to Go in the first place. I'd rather not mention the company, even though I did not work there.

thebean11 6y ago
Yeesh, I can't imagine migrating a large backend codebase from any language to any language. And we're talking about migrating from Java..which is extremely well supported and probably the easiest language to hire for..
nine_k 6y ago
Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.
- Groxx 6y ago
  It makes it easier to start concurrent stuff, but without ready-to-use type-safe abstractions like Java provides I'd say it's far harder to make correct concurrent stuff in Go. And while the race detector is wonderful, especially since it's baked in, it's nowhere near sufficient.
- apta 6y ago
  I disagree. There is so much boilerplate involved with managing concurrency in golang compared to Java. It's very error prone in practice and difficult to extend and manage. golang has nothing remotely close to `java.util.concurrent`.
kjksf 6y ago
And as a counterpoint there are many non-hearsay examples where teams migrated large projects from C++/Java/Python/Ruby/JavaScript to Go. Described publicly like Dropbox's backend migration to Go: https://twitter.com/jamwt/status/629727590782099456 https://twitter.com/jamwt/status/629727590782099456 I could give you tens examples of that, many have been posted on HN.
- the_af 6y ago
  No need to counterpoint my example. The original list of case studies already lists Go's success stories. I was just providing the example the parent post was asking about. And note it's "hearsay" to you only because I didn't name the company and people involved -- because I was told this in confidence -- but this is a major company where I'm from, and their attempt at adopting Go ended up in disaster. Just a data point, that's all.

networkimprov 6y ago

Discord abandoned Go due to GC overhead. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...

naikrovek 6y ago
This is a puzzling decision on Discord's part, because they found the single line of code causing their problem and they didn't think to change that line of code for their own needs. Go distributions include the source for Go itself, so building your own Go binary with your own changes incorporated is dead easy. And, the change they needed is a single-line change, which means it's easy to bring that change forward as new versions of Go are released. Discord: haha, no, that's silly! let's spend 100,000x more effort and rewrite it all in another language! Now, before those of you who learned to argue on the internet extrapolate what I wrote and imagine that I wrote words I didn't write: I'm not saying that Go should never be abandoned for another language. I'm saying that this particular example of this particular choice puzzles me, because of the reasons stated, and ONLY the reasons stated.
- dilyevsky 6y ago
  Not to mention they could’ve probably just updated their old go runtime...
  - aw1621107 6y ago
    IIRC none of the available Go releases at the time the decision to switch to Rust was made (<=1.10, I think?) addressed their particular issue, and by the time a Go release did fix their issue (1.12?) they were pretty far along with their rewrite. Not entirely sure that I have the Go versions right, but that's what I remembered off the top of my head.
    - aw1621107 6y ago
      Just found a comment by a Discord engineer that says that they did try upgrading their Go runtime (presumably when the decision to rewrite was made) [0]: > Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect. [0]: https://old.reddit.com/r/programming/comments/eyuebc/why_discord_is_switching_from_go_to_rust/fgk56y4/ https://old.reddit.com/r/programming/comments/eyuebc/why_dis...

zerr 6y ago

Go is officially banned by Google for Fuchsia: https://fuchsia.dev/fuchsia-src/contribute/governance/policy/programming_languages https://fuchsia.dev/fuchsia-src/contribute/governance/policy...

kyrra 6y ago
There was discussion about this 6 months ago, such as this comment. https://news.ycombinator.com/item?id=22412475 https://news.ycombinator.com/item?id=22412475
Laremere 6y ago
"Banned", while technically accurate, gives the wrong connotation. More precisely, it wasn't selected as one of the languages for the project. That is, Fuchsia has a set of technical challenges, and it is a reasonable engineering practice to select a minimal set of languages to tackle those challenges. Go's doesn't have a unique niche or a dominate strength in an important area when it comes to Fuchsia, so they're not using it. (As I understand that having read your link previously.)

tptacek 6y ago

Case studies like these are always selected because they’re positive; you don’t have to wonder about the biases. Someone else might want to collect the negative cases; Discord, for instance, and their fights with the GC.

typical182 6y ago
I had looked at the Discord GC blog issue [1] fairly carefully, and it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Also, after publishing that blog, they also said they had wanted to try Rust for other reasons: wanted to try out rust as well for services like this, due to adoption elsewhere in the company. Also, after upgrading between 4 golang versions on this service and noticing it didn't materially change performance, we decided to just spend our time on the rewrite (for fun, and latency) and to get a head start into the asynchronous rust ecosystem. [2] And nothing wrong with that decision from my point of view (Rust is great!), but I believe they could have solved it without dropping Go for that particular service that they blogged about, at least as far as I was able to understand. [1] https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to... [2] https://news.ycombinator.com/item?id=22239707 https://news.ycombinator.com/item?id=22239707
- tptacek 6y ago
  I don't think anyone read that case study as somehow disqualifying for Go, so there's no need to litigate it; it's an example of a "Go -> Something Else" case study, that's all.
  - typical182 6y ago
    True, and it was an interesting case study.
- aw1621107 6y ago
  > it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Do you know if that was the case when the decision to switch was made? They said elsewhere they tried Go 1.7-1.10 and none of those solved their issue, and at least back when the blog post was released I couldn't figure out whether the fix for the corresponding issue was known to have been slated for release in the next Go release.

candiddevmike 6y ago

Anything that has to do with UI in my opinion. Go's lack of classes (factories, inheritance, etc) and verbosity make graphical layouts very, very tedious.

throwaway894345 6y ago
I think this is only true for OOP-style "widget-based" UI toolkits. I've had a very good time writing console UIs using a reactive style; obviously console UIs are simpler, but I think when people want inheritance in UIs, it's for things like 2D layout (in typical OOP toolkits, every widget type is derived from some base Widget class that does layout things) which are also present in console UIs. I would be interested to hear rebuttals or other thoughts.
- athrun 6y ago
  Can I ask which reactive-style console UI library you have been enjoying using? Or was it a custom thing you made from scratch?
  - throwaway894345 6y ago
    Custom, made from scratch probably 5 years ago just for fun.

cmrdporcupine 6y ago

Let me just say that I've been at Google for almost 9 years, and have recently started looking for work elsewhere and it seems that Go is far more popular outside of Google than inside it. Which disappoints me because my experiences with the language internally have biased me such that I have no desire to go use it elsewhere. I've said this before, but I think it's a bit dishonest to sell this as a "Google language." It is an accepted language here, along with Python, Java, JS/TS, Dart, and C++. But it is by no means dominant. To put it another way, it seems if the goal is to avoid working in Go I am better off staying @ Google than leaving. And that's weird, and maybe revealing.

tomlu 6y ago
My current and last positions both involve(d) writing (mostly) Go code, so it's definitely possible to find Go jobs within Google.
- apta 6y ago
  OP wants to avoid using golang, not to find a job where he can use it.
Ericson2314 6y ago
If you look at the way the rest of the industry cargo-cults Google, Go almost looks like a false flag attack to increase Google's competitive advantage while the cargo-cults drown in boilerplate and an inability to abstract.
philosopher1234 6y ago
This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.
- cmrdporcupine 6y ago
  Other people have touched on that and I've opined on it in the past, I don't think this is the thread for that. I think you'll find HN is a divided community on golang. Myself I find the language... kind of insulting... in its lack of basic modern constructs. I find its emerging prevalence to be a concerning trend, and I think it's going to lead to a lot of brittle, boilerplate code. Obviously others disagree. I'll leave it at that.

karmakaze 6y ago

I did run into one Go codebase that was closures all the way down. Due to limited abstractions, closures were created and passed around and returned everywhere through so many layers with arbitrary generic naming. It was the worst. At one point I wondered if it was a ploy to ensure employment but I don't think it was.

cpuguy83 6y ago

Honestly any low level/system code is pretty disastrous in Go. Edit: Just to add to that statement: the work stealing goroutine runtime is particularly problematic, certain things are even impossible in go due to it. If you look at runc, large parts of it are written in C and called during init before the runtime is started.

apta 6y ago
Even higher level programs are quite terrible in golang. It seems it's only good for small (usually networked) tools that can perhaps make use of concurrency.

mrkurt 6y ago

We tried to build a JS runtime in Go and it was a disaster. .NET was actually a better choice, though we ultimately went with Rust (and ultimately, ultimately went with Deno ... which also started as Go).

apta 6y ago

In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend to more verbose and error prone code. Monitoring is poor compared to the JVM/.NET, and performance is worse in general. It has very questionable, if not outright bad design decisions (e.g. they wanted to save on keywords so they don't have public/private, so changing the visibility of a variable or function now results in a huge diff if it's used in many places). The list is too long to elaborate on in a few paragraphs.

cpuguy83 6y ago
> so changing the visibility of a variable or function now results in a huge diff if it's used in many places) You can create an exported version of the function (calling into the unexported one), no diff except the new function. But also just updating all the callsights is usually not a huge issue, especially if you are using an IDE such as GoLand.
- apta 6y ago
  > You can create an exported version of the function These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims. I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction
  - cpuguy83 6y ago
    I don't agree with the term "hack" here. Different is not "hack". I maintain some very large codebases. This has never been an issue. If one decides to export a function, the only callers of that function will be from within the package it was defined in already. Even within a package, how many call sites will there actually be and do they need to use the exported version of the function? I'm not saying it's good, or bad, just that in my (fairly extensive) experience it has not been a problem. I do recognize that some people may have problems with it, though.

Inufu 6y ago

I built (at Google) a prototype system in Go, then rewrote complete in C++: - Go was too slow and GC too much overhead (real time analytics) - Error handling and propagation is insanely verbose in Go, the C++ actually was more concise - lack of generics made it impossible to reuse complex high-performance data structures and algorithms even within the project Haven't looked back and between C++, Rust, Swift and Python, I'd never choose to use Go again.