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

231–240 of 269 posts

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

#231

Post by apta »

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…

Once Java gets green threads (project Loom), it will be a no-brainer to pick it when the choice comes between it and golang. Even now, it's almost a no-brainer with superior features and GCs, including the new low latency ZGC.

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

#232

Post by apta »

nine_k wrote: post #171
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.

Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.

I disagree. There is so much boilerplate involved with managing concurrency in golang compared to Java. It's very error prone in practice and difficult to extend and manage. golang has nothing remotely close to `java.util.concurrent`.

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

#233

Post by apta »

cpuguy83 wrote: post #186
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?

Honestly any low level/system code is pretty disastrous in Go. Edit: Just to add to that statement: the work stealing goroutine runtime is particularly problematic, certain things are even impossible in go due to it. If you look at runc, large parts of it are written in C and called during init before the runtime is started.

Even higher level programs are quite terrible in golang. It seems it's only good for small (usually networked) tools that can perhaps make use of concurrency.

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

#234

Post by apta »

tomlu wrote: post #146
cmrdporcupine wrote: post #137

Earlier quoted context omitted.

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.

OP wants to avoid using golang, not to find a job where he can use it.

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

#235

Post by apta »

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?

In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend to more verbose and error prone code. Monitoring is poor compared to the JVM/.NET, and performance is worse in general. It has very questionable, if not outright bad design decisions (e.g. they wanted to save on keywords so they don't have public/private, so changing the visibility of a variable or function now results in a huge diff if it's used in many places). The list is too long to elaborate on in a few paragraphs.

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

#236

Post by jayd16 »

eweise wrote: post #216
jayd16 wrote: post #181

Earlier quoted context omitted.

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.

Ah, agreed. That's a case where it does well, not the only case.

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

#237

Post by nvarsj »

vips7L wrote: post #148
nvarsj wrote: post #134

Earlier quoted context omitted.

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.

Yeah sorry, the Java collections API is pretty great. I meant in terms of raw boilerplate the language requires you to type to get anything done. This is definitely improving, and you can use things like Project Lombok to generate a lot of it.

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

#238

Post by DangitBobby »

Knut4231 wrote: post #52

I came to Go because some Kotlin CLI tools used too much memory and were clumsy to deploy. I'm staying for the standard lib, tooling and stability. Nothing gets out of the way better than Go.

Well, except for maybe a language that doesn't force you to remove (temporarily) unused imports and change your variable name to an underscore if you simply comment out the only section of code that used to refer to it, making your variable freshly un-used. I find there are some highly opinionated, unconfigurable aspects of the language that pretty much only waste time. They actually get in my way constantly.

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

#239

Post by blub »

warent wrote: post #50

I absolutely love using Go. The logical flows for my programs are always so clean and easy to follow thanks to the language. Contrast to C++ in which spaghetti and magic is basically idiomatic. The only downside I can think of is that error/crash recovery is pretty tricky, but it's only really a concern if you're careless with your goroutines. Whenever I work in Go, I have a lot more confidence in the efficiency of r…

"Spaghetti" means that the code is tangled because of improper control flow usage, lack of adequate control flow syntax or the language encouraging certain patterns. There are very few mainstream programming languages which can be said to encourage writing spaghetti code, I can think of VB6 and early versions of PHP which encouraged mixing e.g. HTML with code. Claiming that C++ spaghetti code is idiomatic is nonsense. There are many very popular references on how to structure and design C++ code and idiomatic C++ code is making use of structural, OOP or functional programming where appropriate.

"Magic" refers to the implementation of certain language or library features directly in the compiler without using the language features. C++ is on the least magical side, since the entire standard library and major libraries are implemented exclusively using language features. Everything is specified and C++ is one of the very few languages which has an international standard. It's especially odd to call other languages out for this when Go for example has magical generic data structures when this feature isn't supported by the language.

Next time consider limiting your comment to praising Go and don't pretend that you know enough about other languages to draw a meaningful comparison.

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

#240

Post by cpuguy83 »

apta wrote: post #235
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?

In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend to more verbose and error prone code. Monitoring is poor compared to the JVM/.NET, and performance is worse in general. It has very questionable, if not outright bad design decisions (e.g. they wanted to save on keywords so they don't have public/private, so ch…

> so changing the visibility of a variable or function now results in a huge diff if it's used in many places)

You can create an exported version of the function (calling into the unexported one), no diff except the new function.

But also just updating all the callsights is usually not a huge issue, especially if you are using an IDE such as GoLand.

Post reply on HN