Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New case studies about Google’s use of Go

opensource.googleblog.com

Post reply on HN
Print view View original

151–160 of 269 posts

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

#151

Post by geodel »

Spivak wrote: post #140
geodel wrote: post #117

Earlier quoted context omitted.

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.

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

#152

Post by aw1621107 »

dilyevsky wrote: post #109
naikrovek wrote: post #102

Earlier quoted context omitted.

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…

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 (Not entirely sure that I have the Go versions right, but that's what I remembered off the top of my head.

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

#153

Post by nawgz »

enahs-sf wrote: post #145
nawgz wrote: post #108

Earlier quoted context omitted.

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

Sounds like you're viewing Go as a silver bullet to endemic organizational issues here, and I find it hard to believe your assertion that Go is going to fix an engineering culture where "testing is sparse"

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

#154

Post by aw1621107 »

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…

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

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

#155

Post by [deleted] »

Konohamaru wrote: post #116
naikrovek wrote: post #102

Earlier quoted context omitted.

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…

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.

[deleted]

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

#156

Post by jrockway »

eloff wrote: post #77
blaisio wrote: post #42

Earlier quoted context omitted.

I think you might have bad information. Go is not a systems programming language. You may be thinking of Rust? Go and C++ serve very different needs.

You're being downvoted, but you're correct. Go and C++ have largely different non-overlapping use cases. Go is not a systems language. It's mostly a networked server language with a garbage collector. It's great for writing a wide variety of networked services like HTTP app servers. C++ is great for when you need full control and best possible performance and are willing to pay the hits in complexity, compile time, a…

I think I only agree with you on games and trading software. In games, you have 4ms (assuming an esports game at 240Hz) to read input, read game state from the network, do all your simulation, draw a frame to the screen, and write the results back to the network. There is absolutely no time budget for anything else; in fact, C++ games don't even manage to run at a 240Hz tickrate and just hack around the input / display handling while they wait for 60Hz networking and simulation run in another thread. (Going off topic, the end result of all of this is an incredible example of what "eventual consistency" means in the real world. Play a multiplayer FPS and you'll never use a database in any mode other than strict serializable again.)

For drivers and database implementations, there is more time to do stuff. For example, I wrote a keyboard controller with Tinygo, and it mostly sits around waiting for the USB host's C++ driver to ask it for data. Go isn't adding any latency (and it's not really C++'s fault either; the standard sets a time interval to poll at). And if you wonder what an OS written in Go would look like, look at gVisor. It's not technically an OS, but it does a large number of OS-like things.

Database engines that are focused on throughput rather than latency will also do fine with an occasional GC delay. CockroachDB and InfluxDB have plenty of users.

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

#157

Post by tigershark »

solidasparagus wrote: post #118
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

TS and Golang aren't comparable. I use both and I've never had a case where I needed to decide between the two. Golang is a high performance, modern language without the low-level or legacy headaches of comparably performant languages. Golang was written for an era where network communication and concurrency are commonly necessities and those use cases feel very natural. Typescript is JS (a conversation ending advant…

Maybe you are not really taking full advantage of the powerful type system in typescript if you don’t see any lacks in go type system and if you think that using ‘any’ or the empty interface is perfectly normal?

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

#158

Post by erik_seaberg »

jeffbee wrote: post #114
saagarjha wrote: post #83

Earlier quoted context omitted.

This isn't true at all. Google still runs a lot of backend on Java, for example.

And their backends in C++ dwarf Java and Go backends combined.

In 2015 they were saying that the core of web search (and the large majority of Borg cores) was C++ but the rest of google3 was a 50:50 mix of C++ and Java with a smattering of Python. Nobody I knew was looking seriously at Go.

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

#159

Post by somethingwitty1 »

kevinmgranger wrote: post #115
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…

map/filter and sum types are not about "fun", they're about correctness and expressiveness. map/filter and their equivalent loops are both perfectly readable, but the latter involves more boilerplate.

And I'd disagree. Numerous engineers of differing skill levels (what I deal with day to day), struggle significantly when map/filter are added into the mix. And we may say "get better engineers", but we don't have that ability. We have to write code that is maintainable for the engineers we have and can get (and the ones coming in the future).

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

#160

Post by jeffbee »

erik_seaberg wrote: post #158
jeffbee wrote: post #114

Earlier quoted context omitted.

And their backends in C++ dwarf Java and Go backends combined.

In 2015 they were saying that the core of web search (and the large majority of Borg cores) was C++ but the rest of google3 was a 50:50 mix of C++ and Java with a smattering of Python. Nobody I knew was looking seriously at Go.

I think weighting it by lines of code is pretty misleading. You have to write a zillion lines to make "hello, world!" work in your new language inside their full-custom production environment. I prefer to think of language share in terms of resources committed.
Post reply on HN