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

201–210 of 269 posts

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

#201

Post by erik_seaberg »

solidasparagus wrote: post #185
erik_seaberg wrote: post #176

Earlier quoted context omitted.

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.

I've never found it much more painful to write: for i, c in range col { if c.isReady && convertToX(c).color == "BLUE": return True } (which is not to say I don't miss the map/filter syntax - although I don't miss the bugs related to lazy execution in stuff like LINQ or Spark)

That’s actually pretty good. Most people would use three more lines to create a temporary and break after setting it, and three to nine more depending on how many steps require idiomatic Go error handling.

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

#202

Post by throwaway894345 »

athrun wrote: post #192
throwaway894345 wrote: post #133

Earlier quoted context omitted.

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

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.

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

#203

Post by aw1621107 »

aw1621107 wrote: post #152
dilyevsky wrote: post #109

Earlier quoted context omitted.

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.

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

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

#204

Post by throwaway894345 »

forsakenharmony wrote: post #196
throwaway894345 wrote: post #129

Earlier quoted context omitted.

I agree with this, but I suspect I disagree on the extent to which this is a problem. These things are minor annoyances in my opinion compared to concerns that are largely apart from the actual language itself, such as performance, ecosystem, tooling, deployment story, learning curve, etc. With respect to Python and JS, you can always drop down to `interface{}` for similar expressive power and type safety, but genera…

> its tooling story is simply top-notch on the whole (of course, there are individual tool categories where other languages have better offerings). Personally feel like rust is better overall, but I don't know if you've tried it

I have, and I generally agree. Rust’s tooling is fantastic. Compiler needs a speed up, but impressive work all around. Would like to be able to use it more often.

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

#205

Post by the_af »

kjksf wrote: post #187
the_af wrote: post #81

Earlier quoted context omitted.

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.

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.

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

#206

Post by pansa2 »

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 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 basic operations on slices: https://github.com/golang/go/wiki/SliceTricks

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

#207

Post by eloff »

jrockway wrote: post #156
eloff wrote: post #77

Earlier quoted context omitted.

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 / displ…

I think GC is not harmful than helpful in drivers and things like an OS. gVisor in particular jumps through hoops for performance and still has poor performance. It could be more successful in C++ or Rust probably.

I like Go a lot, but if you needed the performance or manual control it is not the tool for the job. On the other hand most problems don't fit that description and Go is one of the best choices for them.

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

#208

Post by aw1621107 »

hu3 wrote: post #190
kjksf wrote: post #188

Earlier quoted context omitted.

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]:

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

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

#209

Post by amscanne »

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…

Interesting. I didn’t know you could do that in python with a list.

It would be trivial for Go to support the delete keyword on slices (mapping to the statement you noted), but I think it would be a bad idea. Sometimes you want an operation to be awkward intentionally because it’s fundamentally costly. Hiding that cost by making everything look the same doesn’t always help the programmer. Languages should be powerful, but there should be an intuitive relationship between the code the computational complexity (not exact, but intuitive).

I’m sure there are counter examples, but I think Go generally does a good job at this. Plain loops are standard, make, append, new, delete, etc. have obvious costs. Error handling is explicit.

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

#210

Post by ecnahc515 »

Guthur wrote: post #183
somethingwitty1 wrote: post #159

Earlier quoted context omitted.

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

Come on, map and filter difficult? That's hyperbole of the highest order.

Not really. They require a basic understanding of higher order functions and often heavily use closures. Those moderately advanced concepts. It’s also sometimes harder to write efficiently to avoid multiple iterations over the same collection. I think many many people are way more comfortable with loops than people are with map/filter.
Post reply on HN