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

161–170 of 269 posts

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

#161

Post by saagarjha »

throwaway894345 wrote: post #129
erokar wrote: post #91

Earlier quoted context omitted.

I share much of the sentiment. I like the simplicity of Go, but I think they took it too far an ended up with something too dumbed down and lacking in abstractions and expressive power. It feels like a step backwards coming from other contemporary and popular languages like JS/TS, Python, Kotlin, C#.

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…

Python also actively hates functional programming and certain other language features that it "has", plus its standard library is extensive but also all over the place.

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

#162

Post by Ericson2314 »

cmrdporcupine wrote: post #137
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?

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

If you look at the way the rest of the industry cargo-cults Google, Go almost looks like a false flag attack to increase Google's competitive advantage while the cargo-cults drown in boilerplate and an inability to abstract.

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

#163

Post by bit_logic »

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

Because of this, I'm mostly interested in only Go and Java. Go obviously avoids the async/await trap with its core feature, goroutines. Java managed to resist this trap and has Project Loom coming which will give it the same feature as goroutines, but in a backwards compatible way.

Go is criticized for not having generics, but I appreciate the slower and more thoughtful way both languages add new features. Javascript, C#, etc. these languages seem to add whatever FOMO driven new hyped language feature is popular at the moment. Many complain about Go taking so long to add generics, just like many complained about lambdas in Java. But evolving a language should not be done quickly and recklessly.

My focus is still on Java, but I'm occasionally looking at Go to see what they're doing. It's interesting watching these two languages become more like each other (generics in Go and fibers in Java).

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

#164

Post by karmakaze »

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 did run into one Go codebase that was closures all the way down. Due to limited abstractions, closures were created and passed around and returned everywhere through so many layers with arbitrary generic naming. It was the worst. At one point I wondered if it was a ploy to ensure employment but I don't think it was.

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

#165

Post by yencabulator »

piazz wrote: post #104
skywhopper wrote: post #97

Earlier quoted context omitted.

This sort of comment is not really relevant to the article that was posted, which is not about Go's type system, or convincing TypeScript users to switch to Go. I'm sorry that you don't like Go's types, but I'm going to guess it's not really targeted at your needs if you are a TS user. It's okay not to use Go for your projects. But there's no need to drop your personal opinion of a language into a post about specific…

Other comments on this post: > I absolutely love using Go. The logical flows for my programs... > Go is super productive. My day-to-day responsibilities include... > Nothing gets out of the way better than Go. > Go as a new language is a mega success. I'm guessing you're OK with these, and maybe it's just negative opinions that are irrelevant?

It's pretty much guaranteed there can't be anything posted about Go without that predictable comment on how bad it is. It's very repetitive, and hence annoying and not adding value.

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

#166

Post by tigershark »

nedsma wrote: post #94

Go is super productive. My day-to-day responsibilities include development in .NET and Go. A full day working in Go is like a having a pleasant day off. On the other hand, .NET is so cumbersome, complex and verbose (I've been using it since its inception), that I'd rather abandon it for good if possible.

.NET is not a language. Are you using C#, VB.NET or F#?

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

#167

Post by azakai »

piazz wrote: post #104
skywhopper wrote: post #97

Earlier quoted context omitted.

This sort of comment is not really relevant to the article that was posted, which is not about Go's type system, or convincing TypeScript users to switch to Go. I'm sorry that you don't like Go's types, but I'm going to guess it's not really targeted at your needs if you are a TS user. It's okay not to use Go for your projects. But there's no need to drop your personal opinion of a language into a post about specific…

Other comments on this post: > I absolutely love using Go. The logical flows for my programs... > Go is super productive. My day-to-day responsibilities include... > Nothing gets out of the way better than Go. > Go as a new language is a mega success. I'm guessing you're OK with these, and maybe it's just negative opinions that are irrelevant?

I'm not the person you're responding to, but I think there is a difference between positive and negative posts in this context.

Negativity is inherently bad. There is a place for it, of course, but when it's off-topic it's especially unwelcome in my opinion. And programming language discussion already has far too much negativity.

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

#168

Post by AlphaSite »

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…

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.

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

#169

Post by nine_k »

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…

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.

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

#170

Post by jayd16 »

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.
Post reply on HN