Hacker News Reader

Comment by mabbo | Hacker News Reader

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?

View on HN

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.

My current and last positions both involve(d) writing (mostly) Go code, so it's definitely possible to find Go jobs within Google.

OP wants to avoid using golang, not to find a job where he can use it.

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.

This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.

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.

But whats the point of coming in this thread and insulting the language repeatedly without explaining any of your insults? why do you feel like this type of unconstructive criticism is appropriate in this thread, and actually explaining your point of view is not?

The thread is about Go language adoption, and so I stayed on that topic. I made a remark about my observations of the language adoption within Google, and what I perceive outside of Google. The bits about my tastes for this are a personal commentary and are related to why I'm interested in this topic: I don't like the language and don't want to work in it.

I don't really care that you find that un-constructive, as you can go elsewhere to get people's critiques of the language, there are plenty of them and they come up every time someone posts about Go here. My opinion is certainly not unique on this subject.

I just find it frustrating that your comment is "i'm a google engineer and I hate the language and so does everyone else at google" but you refuse to explain why you feel that way. As someone who likes go, I find this comment to be basically "go is bad because google engineers dont like it" which is the exact type of appeal to authority/cargo culting you seem to be criticizing.

If you're going to trash something at least put in enough effort to explain yourself. Otherwise I think this thread was better off without your comment.

Pretty sure it wasn't "so does everyone else at Google." I challenge you to find that quote. Not at all representative of what I said. Stop casting aspersions on me.

I think you might be a little too emotionally attached to Go? I am allowed to have a subjective opinion on Go and voice it in public discussion forum. This is not a scientific paper or journal article.

You're allowed to do whatever you want, as am I. I claim that your comment was unconstructive and paraphrased the meaning of your comment. I didn't learn anything about the weaknesses of Go from reading your comment, I learned that you don't like it and there was a vague suggestion that it is unpopular at google, and that the reason its popular outside of google has to do with cargo culting. But you neglected to express why you thought its weaknesses of go (what are those weaknesses?) that leads to this situation.

I would genuinely like to know what your criticism of the language is, but you haven't offered any. The comment you wrote does not add any clarity to the discussion of Go, in fact I think it takes away clarity by relying on suggestion and avoiding grappling with any details. I think it was not a useful contribution to this thread. I'll leave it at that.

cmrdporcupine stated, at least once, that he didn't consider his reasons for disliking Go to be on-topic for this thread. You seem obsessed with trying to pry the reason out of him. He said he's not going to answer; let it go.

If you have to have an answer, he said he's opined on it in the past. Go trawl through his past comments. (Google search might help.)

> it seems that Go is far more popular outside of Google than inside it

Blame the cargo cult and hype driven development for that one.

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.

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

Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.

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.

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`.

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

I could give you tens examples of that, many have been posted on HN.

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.

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

There was discussion about this 6 months ago, such as this comment.

https://news.ycombinator.com/item?id=22412475

"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.)

Discord abandoned Go due to GC overhead.

https://blog.discord.com/why-discord-is-switching-from-go-to...

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.

Not to mention they could’ve probably just updated their old go runtime...

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.

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_dis...

There's a Serbo-Croatian proverb: "what you don't have in head you have in feet." That is, what you can't do by thinking a little bit means you must do by expending pointless effort instead.

Besides all you said, Discord client is electron based bloated software. So it just seems a case when some engineers itching to write Rust and decided to make virtue out of it.

But they’re specifically talking about a server component here. Using Electron on the client doesn’t magically make their need for a high performance backend disappear. They’re still having to make all those clients work and deliver voice chat to millions of simultaneous users.

Yes of course they are. Further I understand the "strategic decisions", "markets have spoken" , "faster feature due to single codebase" justifications to Electron usage. To me it just feels like saying we care about our servers meanwhile users can eat crap.

Yeah, one is free, one isnt

Bad UX is not free at all.

That's not what the article is saying.

It describes a rewrite of a single service from Go to Rust.

Reading between the lines, a rather simple piece of code.

At no point it implies that Discord rewrote all their Go code in Rust and completely abandoned Go.

Top-voted comment on that post raises some red flags.

> Any reason you’re using 3-year-old Go 1.9.2 but you’re okay using Rust nightly?

A Reddit comment by a Discord engineer addresses the old Go part [0]:

[0]: https://old.reddit.com/r/programming/comments/eyuebc/why_dis...

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.

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

[2] https://news.ycombinator.com/item?id=22239707

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.

True, and it was an interesting case study.

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

> Do you know if that was the case when the decision to switch was made?

It’s a good question.

The timing is a bit confusing because the blog was apparently published a bit after the fact, but I think I saw that they said they made the decision mid 2019.

Go 1.12 seemed to address their latency issue, which was available as GA in Feb 2019.

That’s based on some retroactive benchmarks on a set of old Go versions starting with 1.9 and targeting what they described as the problem and symptoms.

Things seemed to line up, but I can’t be sure.

I don’t know if Go 1.11 would have addressed their issue.

(In general, Go GC tail latencies including for large heaps have improved a bunch since the last version they said they tried, which I think was Go 1.10).

In any event, they saw a problem, and made a rationale decision for multiple rationale reasons.

After digging a bit more, I found a comment from a Discord engineer that seems to clear things up [0]:

So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon.

That being said, I have no idea if work to fix this issue was visible on Go's Github, so maybe the Discord engineers were unaware of said work or were unhappy with the pace of progress.

Kind of miffed at myself for missing that comment, since it directly addresses my question, but at least it's answered now.

[0]: https://old.reddit.com/r/programming/comments/eyuebc/why_dis...

Based on reading through various posts from Discord people after that blog was posted, my understanding was there was a material gap in time between the last time they tried in earnest to solve the latency issue with Go (with Go 1.10, as in your quote) vs. when they later did the re-write in Rust.

It seems during that gap in time, the Go runtime team happened to solve their problem, which was GA in Go 1.12 in Feb 2019, which was prior to them doing the re-write in Rust, at least as far as I was able to follow.

One imprecise quote on timing of the re-write: [1]

This blog post perhaps is a bit "after the fact" we had made the switch over mid 2019

It's not crazy for someone to put aside a problem for a while, and then upon returning to the problem some time later decide to go a different route without re-exploring prior solutions, if that is what happened.

All that said, I might have misunderstood the timing, and I'm trying to avoid going back over all the various forums they commented in to find a better quote on timing ;-)

[1] https://news.ycombinator.com/item?id=22239707

I think it comes down to what "we had made the switch over mid 2019" is supposed to mean. I had interpreted that as being the time the Rust implementation was put into production and the Go implementation retired, with the rewrite starting some time before then, but I don't really have any strong evidence to support that interpretation (and that interpretation doesn't say anything about the actual point at which the rewrite decision was made).

The situation you describe is certainly plausible, though. Shame that the chances of finding out what actually happened are quite low at this point.

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.

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.

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).

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.

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.

Can I ask which reactive-style console UI library you have been enjoying using? Or was it a custom thing you made from scratch?

Custom, made from scratch probably 5 years ago just for fun.

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.

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.

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.

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

> 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

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.

My experience has been otherwise, it's been extremely friction-inducing and I had to go out of my way to split up diffs into smaller ones in order to make it clear what was going on. A language like Java or C# would have just had a single line difference (`-private +public`) and be done.

Reply on news.ycombinator.com