Live data from Hacker News

New case studies about Google’s use of Go

opensource.googleblog.com

241–250 of 269 posts

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

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

> it seems that Go is far more popular outside of Google than inside it

Blame the cargo cult and hype driven development for that one.

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

#242

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

This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.

Other people have touched on that and I've opined on it in the past, I don't think this is the thread for that. I think you'll find HN is a divided community on golang. Myself I find the language... kind of insulting... in its lack of basic modern constructs. I find its emerging prevalence to be a concerning trend, and I think it's going to lead to a lot of brittle, boilerplate code. Obviously others disagree. I'll leave it at that.

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

#243
post #77
post #42

Earlier quoted context omitted.

I think you might have bad information. Go is not a systems programming language. You may be thinking of Rust? Go and C++ serve very different needs.

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 a lot of people just assume there's a ton of overlap because Go is AOT compiled into a single binary (like Rust and C/C++). As silly as that is.

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

#244
post #153

Earlier quoted context omitted.

our JS build time was hovering around 30m for small changes. I built a proof-of-concept backend in go (basically a mirror of some existing services), and was able to build and deploy it in no time flat. No one knew typescript at our org, but that was a much easier sell despite slowing down the build and HMR significantly. It was not for lack of knowledge of go either; there were several developers on the team with st…

Sounds like you're viewing Go as a silver bullet to endemic organizational issues here, and I find it hard to believe your assertion that Go is going to fix an engineering culture where "testing is sparse"

We tried to write tests, but they took too long to run. Also there was a great debate over which of the numerous testing frameworks to choose from? Chai? mocha? Cypress for end to end? How it all fits in the CI pipeline? For unit testing, go has a great built-in solution, and with testify you can get the rest of the way there.

I don't think go is a silver bullet solution, but when I see something I know can be a lot better and simpler, I generally tend to gravitate towards that.

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

#245

Earlier quoted context omitted.

This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.

Other people have touched on that and I've opined on it in the past, I don't think this is the thread for that. I think you'll find HN is a divided community on golang. Myself I find the language... kind of insulting... in its lack of basic modern constructs. I find its emerging prevalence to be a concerning trend, and I think it's going to lead to a lot of brittle, boilerplate code. Obviously others disagree. I'll l…

But whats the point of coming in this thread and insulting the language repeatedly without explaining any of your insults? why do you feel like this type of unconstructive criticism is appropriate in this thread, and actually explaining your point of view is not?

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

#246
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 built (at Google) a prototype system in Go, then rewrote complete in C++:

- Go was too slow and GC too much overhead (real time analytics)

- Error handling and propagation is insanely verbose in Go, the C++ actually was more concise

- lack of generics made it impossible to reuse complex high-performance data structures and algorithms even within the project

Haven't looked back and between C++, Rust, Swift and Python, I'd never choose to use Go again.

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

#247
post #126
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 would be embarrassed to admit the amount of times I have discovered this in my Python code for foo in ... if i in foo: creating something of quadratic complexity! Yes, I would rather take the explicitly verbose Go code To be clear: If foo is a dict, we have one loop. If foo is a list, we have two loops. If accidentally happens to be a string, even then it is nested loops

Isn't this just an issue of having types, versus not?

Although I do remember trying racket, where they solved the same problem by naming functions dict-remove set-remove hash-remove vector-drop etc, which does the job but never have I been more offended thinking I was going in for its abstraction capabilities

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

#248

Earlier quoted context omitted.

Other people have touched on that and I've opined on it in the past, I don't think this is the thread for that. I think you'll find HN is a divided community on golang. Myself I find the language... kind of insulting... in its lack of basic modern constructs. I find its emerging prevalence to be a concerning trend, and I think it's going to lead to a lot of brittle, boilerplate code. Obviously others disagree. I'll l…

But whats the point of coming in this thread and insulting the language repeatedly without explaining any of your insults? why do you feel like this type of unconstructive criticism is appropriate in this thread, and actually explaining your point of view is not?

The thread is about Go language adoption, and so I stayed on that topic. I made a remark about my observations of the language adoption within Google, and what I perceive outside of Google. The bits about my tastes for this are a personal commentary and are related to why I'm interested in this topic: I don't like the language and don't want to work in it.

I don't really care that you find that un-constructive, as you can go elsewhere to get people's critiques of the language, there are plenty of them and they come up every time someone posts about Go here. My opinion is certainly not unique on this subject.

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

#249
post #126
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 would be embarrassed to admit the amount of times I have discovered this in my Python code for foo in ... if i in foo: creating something of quadratic complexity! Yes, I would rather take the explicitly verbose Go code To be clear: If foo is a dict, we have one loop. If foo is a list, we have two loops. If accidentally happens to be a string, even then it is nested loops

This seems like a misunderstanding of quadratic complexity. If every i in every foo is checked/operated upon once, that's still linear, no matter if the nesting structure requires nesting flow control.

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

#250

Earlier quoted context omitted.

But whats the point of coming in this thread and insulting the language repeatedly without explaining any of your insults? why do you feel like this type of unconstructive criticism is appropriate in this thread, and actually explaining your point of view is not?

The thread is about Go language adoption, and so I stayed on that topic. I made a remark about my observations of the language adoption within Google, and what I perceive outside of Google. The bits about my tastes for this are a personal commentary and are related to why I'm interested in this topic: I don't like the language and don't want to work in it. I don't really care that you find that un-constructive, as yo…

I just find it frustrating that your comment is "i'm a google engineer and I hate the language and so does everyone else at google" but you refuse to explain why you feel that way. As someone who likes go, I find this comment to be basically "go is bad because google engineers dont like it" which is the exact type of appeal to authority/cargo culting you seem to be criticizing.

If you're going to trash something at least put in enough effort to explain yourself. Otherwise I think this thread was better off without your comment.

Post reply on HN