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

211–220 of 269 posts

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

#211

Post by icholy »

eweise wrote: post #177
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…

I get the feeling that Go programmers came from some other imperative language and got burned by some OO features. I feel kind of bad for them. I hope they never discover modern functional features or they will realize how much of their life was wasted writing pointless boilerplate.

The time spent writing boilerplate is completely negligible to the amount of time spent finding the "perfect" combination of language features to express your problem. I write production ready code in Go way faster than in any other language I've used.

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

#212

Post by Abishek_Muthian »

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…

>Golang was designed for getting shit done

That's indeed a good way to explain the utility driven nature of Go. I've been predominantly using OOP languages before and Go's deliberate lack of OOP features was although uncomfortable at first, the advantages of getting things done fast far outweighed it later when I released production applications with it.

>For me, Golang is like Python but with static typing and high performance. Fast to implement, easy to read, and focused on getting code out the door.

I was tired of adding disclaimer when teaching Python, that when you want to extract performance out of it you should also learn 'C/C++'. Go serves as a perfect replacement to Python where performance is a necessity, I don't see where that would be false in a production environment where 'code performance == capital efficiency'.

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

#213

Post by solidasparagus »

pansa2 wrote: post #206
solidasparagus wrote: post #118

Earlier quoted context omitted.

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…

> Golang is like Python [...] Fast to implement, easy to read I disagree. Python is often described as "executable pseudocode" - for example, to delete the `i`th element from a list `a` you use `del a[i]`. In Go, it's much more convoluted: `a = append(a[:i], a[i+1:]...)`. Plus, without generics, you can't even easily hide that inside a function! There's a whole page of these "tricks" that are necessary to perform bas…

Yeah, Python is much much more readable than Go. I feel like performance focused languages are always less readable because the language needs to give you more control and I think Golang lets you work at a pretty high level of abstraction while still having plenty of control on performance. Once you know Go, it's pretty easy to read someone else's code, which I think is really nice. But "easy to read" might have been a little bit of a stretch.

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

#214

Post by zemo »

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…

a quick grep on my project and I'm counting 779 functions. the empty interface appears in 12 of the 779 function signatures. If you find yourself constantly using the empty interface it's because you don't know the language, not because it's necessary.

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

#215

Post by fomine3 »

bit_logic wrote: post #163

async/await colored functions is a disaster: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... And so many languages and ecosystems have fallen to this. Even C#, which is surprising since I expected them to know better. There was so much hype about async/await (nodejs was a big factor for this hype), that many languages adopted this without fully considering the long term maintenance nightmare it will c…

There's still some problem for async/await but I won't say it "disaster". I don't think Java is good by not improving async systems.

I like Go's thoughtful adoption but personally I wonder they can do faster.

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

#216

Post by eweise »

jayd16 wrote: post #181
eweise wrote: post #178

Earlier quoted context omitted.

Async / await is just an abstraction over threads. It doesn't dictate how many threads are used.

I'm not sure what your point is exactly but I would disagree with the presented assertions none the less. In C# async/await is essentially sugar around callbacks, which isn't really related to threads, per se. However, the language has the Task Parallel Library, and a Task promise type that has a lot of methods around scheduling and thread targeting. Essentially the TPL does dictate how many threads are used and is,…

My reply was in response to "Async/await works well when you need to manage scheduling of a single thread" My point being that it isn't limited to cases where you only have a single thread.

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

#217

Post by typical182 »

aw1621107 wrote: post #200
typical182 wrote: post #195

Earlier quoted context omitted.

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

After digging a bit more, I found a comment from a Discord engineer that seems to clear things up [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. So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon. That being sa…

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

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

#218

Post by _y5hn »

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…

Go is designed to be performant by default, so expensive operations will stick out in code. It is high level, but also like a "better C".

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

#219

Post by _y5hn »

erik_seaberg wrote: post #176
nine_k wrote: post #169

Earlier quoted context omitted.

I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.

I think some people feel productive when they write out a big loop, but to me it’s wasted effort. I want to write col.filter(_.isReady).map(convertToX).any(_.color == BLUE) and generate whatever fused loops make that work. I don’t want to write and review loop boilerplate by hand for the same reason that I don’t want to customize the stack frame layout when I call a function.

This style makes developer forget the underlying costs though. It feels productive but it is harder to understand what work computer will do. Go is designed to be imperative, so is a complementary language.

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

#220

Post by _y5hn »

piazz wrote: post #197
nine_k wrote: post #169

Earlier quoted context omitted.

I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.

I'm also majorly turned off by this attitude. We're knowledge workers - ostensibly paid nice salaries to think deeply and find reasonable solutions to hard problems, not just to turn a crank and shit out code as fast as possible. Sure, this is not your job 24/7, and there will always be boring code to write, but still, have some pride in your craft, you know?

The point of code is readability and runtime, not ego-stroking. Fast compile times are a bonus!
Post reply on HN