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

171–180 of 269 posts

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

#171

Post by nine_k »

the_af wrote: post #81
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?

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.

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

#172

Post by solidasparagus »

AlphaSite wrote: post #168
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…

IMO Go's biggest issue is its lack of the functional features which have trickled into most languages (although arguably without generics, this is impossible to implement). I dont particularly want Haskell with semi colons and braces, but a functional style definitely has its place. Just like Go has a subset of the traditional object oriented style, i think there is a place for a subset of functional.

What do you miss? All I've ever really needed is the ability to pass around functions as first class primitives which Golang has.

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

#173

Post by solidasparagus »

nine_k wrote: post #169
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…

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.

Are you suggesting that Golang leads to to poor quality software? That hasn't been my experience.

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

#174

Post by nine_k »

solidasparagus wrote: post #173
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.

Are you suggesting that Golang leads to to poor quality software? That hasn't been my experience.

No, I specifically quote words from the comment to which I'm replying.

The problem is language-independent, but is more pronounced among adepts of "practical" languages and tools.

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

#175

Post by tmerr »

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…

Complicated languages come with an explosion in number of ways to do things.

Rust is great but I waste a lot of cycles thinking about how to structure the code instead of the actual problem. What is cleaner here using a loop or a higher order function? Should I use if let to make the code a little shorter? Should I use that question mark trick to propagate the error? Do I use the expression or statement form of ifs?

Do all of the features in your language really make you more productive, or are the gains offset by the cognitive burden of dealing with them? And what is the cost of having many ways to do things in the context of a code review? What about when reading other people's code? What about when writing automatic tooling?

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

#176

Post by erik_seaberg »

nine_k wrote: post #169
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…

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.

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

#177

Post by eweise »

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.

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

#178

Post by eweise »

jayd16 wrote: post #170
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…

Async/await solves a different problem than green threads. Async/await works well when you need to manage scheduling of a single thread (very common in UI or other cross runtime tasks). Implicit green threads are nice if all you care about is total throughput across all threads. Its not great for keeping a single thread responsive.

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

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

#179

Post by pm90 »

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.

And I feel bad for those who pontificate over the lack of features for a language that’s easy to use, has a simple build system and allows for solving many classes of problems very easily.

Golang is popular for a reason. It is popular even among programmers that enjoy using other languages. No need to feel bad for programmers who are happily building things.

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

#180

Post by pm90 »

qaq wrote: post #135
bengalister wrote: post #105

Earlier quoted context omitted.

I still find the Typescript compilation time to be annoying. I rediscovered using Typescript for backend development on NodeJs and was very unpleasantly surprised by the compilation time (my only complaint). For a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile and 4Gb of RAM (yes I checked with tsc --listFiles that no other files were parsed). The same in Go to compile to native…

TypeScript has way more advanced type system so there is a price you pay for that.

IIUC, this is specifically a problem with the TS build system/runtime, not because it’s typed. Deno is attempting to solve that.
Post reply on HN