New case studies about Google’s use of Go
opensource.googleblog.com
New case studies about Google’s use of Go
1–10 of 269 posts
Re: New case studies about Google’s use of Go
#2> Go also powered Google’s development and launch of Kubernetes in 2014.
Wasn't k8s written originally in Java and only ported to Go later on?
Re: New case studies about Google’s use of Go
#3> Go also powered Google’s development and launch of Kubernetes in 2014. Wasn't k8s written originally in Java and only ported to Go later on?
I think it's fair to say both statements are true:
> Kubernetes was built on ideas that had been proven out at Google over the previous ten years with Borg. And Borg, itself, owed its existence to even earlier efforts at Google and beyond.
> Concretely, Kubernetes started as some prototypes from Brendan Burns combined with ongoing work from me and Craig McLuckie to better align the internal Google experience with the Google Cloud experience. Brendan, Craig, and I really wanted people to use this, so we made the case to build out this prototype as an open source project that would bring the best ideas from Borg out into the open.
> After we got the nod, it was time to actually build the system. We took Brendan’s prototype (in Java), rewrote it in Go, and built just enough to get the core ideas across. By this time the team had grown to include Ville Aikas, Tim Hockin, Brian Grant, Dawn Chen and Daniel Smith. Once we had something working, someone had to sign up to clean things up to get it ready for public launch. That ended up being me. Not knowing the significance at the time, I created a new repo, moved things over, and checked it in. So while I have the first public commit to the repo, there was work underway well before that.
Re: New case studies about Google’s use of Go
#4I 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.
Re: New case studies about Google’s use of Go
#5> Looking back from 2020, Go has succeeded in both ways: it is widely used both inside and outside Google, and its approaches to network concurrency and software engineering have had a noticeable effect on other languages and their tools.
Don’t know much about go myself, but I’m interested in examples of this.
Re: New case studies about Google’s use of Go
#6Kinda tired of the proliferation of languages coming out of Google, whether they actually created them or not.
If Go is so great, why was Kotlin released four years later and made the standard on Android? It's annoying enough to have to use Swift and Kotlin for iOS/Mac vs. Android. Now Go? What happened to Dart?
Then there's Rust. What about next week?
Re: New case studies about Google’s use of Go
#7I 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.
Re: New case studies about Google’s use of Go
#8You can see more very exciting case studies of companies using Go here, didn't know until now Twitch or Facebook (and even Target!) uses Go a lot.
Re: New case studies about Google’s use of Go
#9> Looking back from 2020, Go has succeeded in both ways: it is widely used both inside and outside Google, and its approaches to network concurrency and software engineering have had a noticeable effect on other languages and their tools. Don’t know much about go myself, but I’m interested in examples of this.
Arguably opinionated formatters like prettier and black are a response to gofmt.
Re: New case studies about Google’s use of Go
#10I 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.
It's funny, if you'd asked me almost a decade ago which language would compete with Go, I would not have answered "JavaScript"! Yet, these days I find that's the trade-off: build something "quick" in TypeScript that's easy to modify but perhaps a bit brittle and slow(er) to run in production, vs build something very considerate and optimized in Go but perhaps not something you can easily change without hiring folks specifically for the backend.
And then you've Java, which is now trying to be the "VM for every runtime" but is still best at Java itself, for now. I tried running JS-on-Java (graaljs) to improve the performance of JavaScript from "only twice as fast as Python" to "within the top 10 on TechEmpower" but found it had too many compromises to rely on it, it was just another runtime layer I would have to worry about.
I end up wondering if the solution really is to begin by prototyping efforts in slower-executing languages to start except where existing conditions and code ecosystems might allow for faster initial results in another language. (Kubernetes projects should likely use Go, etc.) Which is less about Go and more about the need to rewrite software later, I suppose.
Then again, these days the problems I end up spending (too much) time on are "which dependency should I use," or "should I rewrite the dependency," I rarely ask myself which language is "better" for a task because I end up having to use languages others are familiar with. Go is not yet universally one of those languages, but the more I see unfamiliar Go code in the wild, the more I feel it could be. One of its current strengths is that its simple syntax and maybe its repetitiveness also makes it quite easy to follow for newcomers.