New case studies about Google’s use of Go • Hacker News Board

Re: New case studies about Google’s use of Go

#141

Post by typical182 » Thu, Aug 27, 2020, 9:38 PM UTC

tptacek wrote: post #96

mabbo wrote: post #75

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?

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

Re: New case studies about Google’s use of Go

#142

Post by sanxiyn » Thu, Aug 27, 2020, 9:45 PM UTC

TillE wrote: post #125

ngrilly wrote: post #24

Earlier quoted context omitted.

Google Translate, for example, is amazing.

Google Translate produces mediocre results with European languages and absolute gibberish with Chinese or Japanese. Personally, Google Translate is my litmus test for "is ML actually any good". If we ever reach the point of fluent translation of German or coherent translation of Japanese, I will be extremely impressed.

Automatically producing mediocre results is amazing.

So: Google Translate IS amazing. The result of Google Translate is definitely not amazing, but that wasn't the claim.

Re: New case studies about Google’s use of Go

#143

Post by tptacek » Thu, Aug 27, 2020, 9:49 PM UTC

typical182 wrote: post #141

tptacek wrote: post #96

Earlier quoted context omitted.

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 upgrad…

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.

Re: New case studies about Google’s use of Go

#144

Post by typical182 » Thu, Aug 27, 2020, 9:59 PM UTC

tptacek wrote: post #143

typical182 wrote: post #141

Earlier quoted context omitted.

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 upgrad…

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.

Re: New case studies about Google’s use of Go

#145

Post by enahs-sf » Thu, Aug 27, 2020, 10:00 PM UTC

nawgz wrote: post #108

enahs-sf wrote: post #4

I tried very hard to bring go into my previous employers environment, but it was all for naught. They are too bought into the JavaScript stack. Case studies like this would have been super helpful in trying to make my claims.

As a JS dev - the strength of a vertically integrated stack is high. I have a collaborative model editor which can run plugins on the model, and these plugins can be configured to run on the client or the server depending on what they do and what kind of requests they need. This exact same language fuels my API and my client. It means I can share packages everywhere, and a problem solved once & put in a library is so…

our JS build time was hovering around 30m for small changes. I built a proof-of-concept backend in go (basically a mirror of some existing services), and was able to build and deploy it in no time flat.

No one knew typescript at our org, but that was a much easier sell despite slowing down the build and HMR significantly.

It was not for lack of knowledge of go either; there were several developers on the team with strong go backgrounds.

Management was unsure of it as "new" technology despite using next.js, typescript. Really, they just were afraid of switching.

To your point about a vertically integrated stack, this is great in an small to medium environment but on a large (and quickly growing team) where the CI looks like a christmas tree and testing is sparse, it was actually quite difficult to manage. Maybe i'll muster up the courage to write a medium post one of these days.

Re: New case studies about Google’s use of Go

#146

Post by tomlu » Thu, Aug 27, 2020, 10:01 PM UTC

cmrdporcupine wrote: post #137

mabbo wrote: post #75

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?

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

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

Re: New case studies about Google’s use of Go

#147

Post by enahs-sf » Thu, Aug 27, 2020, 10:02 PM UTC

game_the0ry wrote: post #7

enahs-sf wrote: post #4

I tried very hard to bring go into my previous employers environment, but it was all for naught. They are too bought into the JavaScript stack. Case studies like this would have been super helpful in trying to make my claims.

The good news is that this case study means you were probably right to bring it up as a worthwhile consideration, and you will have these case studies to point to next time.

nah, I just quit and started my own company instead. Now I use go on the backend. problem solved.

Re: New case studies about Google’s use of Go

#148

Post by vips7L » Thu, Aug 27, 2020, 10:06 PM UTC

nvarsj wrote: post #134

yandrypozo wrote: post #110

Earlier quoted context omitted.

the key is simplicity, you're complaining about language features that allow you to write "fun" code, but remember that we spend around 80% of the time reading or debugging code, the main focus of Go is about writing code that's easy to read which will allow you to scale a project or source code with more people, also remember that easy doesn't mean simple, I think these 2 talks will make you understand my idea a lit…

I love go but the OP is completely right. Lack of basic collection functions is incredibly aggravating and slows down productivity substantially. At least it's not as bad as Java.

I'm not sure how you can have that opinion of Java when Go is basically Java pre-generics. Especially in the context of collection functions. Java's stream API is simply amazing.

Re: New case studies about Google’s use of Go

#149

Post by DaiPlusPlus » Thu, Aug 27, 2020, 10:15 PM UTC

nvarsj wrote: post #134

yandrypozo wrote: post #110

Earlier quoted context omitted.

the key is simplicity, you're complaining about language features that allow you to write "fun" code, but remember that we spend around 80% of the time reading or debugging code, the main focus of Go is about writing code that's easy to read which will allow you to scale a project or source code with more people, also remember that easy doesn't mean simple, I think these 2 talks will make you understand my idea a lit…

I love go but the OP is completely right. Lack of basic collection functions is incredibly aggravating and slows down productivity substantially. At least it's not as bad as Java.

Java's photocopy of .NET's Linq in the form of "Streams" is usable.

Re: New case studies about Google’s use of Go

#150

Post by Laremere » Thu, Aug 27, 2020, 10:18 PM UTC

zerr wrote: post #92

mabbo wrote: post #75

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?

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

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