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

251–260 of 269 posts

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

#251

Post by cmrdporcupine »

philosopher1234 wrote: post #250
cmrdporcupine wrote: post #248

Earlier quoted context omitted.

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

Pretty sure it wasn't "so does everyone else at Google." I challenge you to find that quote. Not at all representative of what I said. Stop casting aspersions on me.

I think you might be a little too emotionally attached to Go? I am allowed to have a subjective opinion on Go and voice it in public discussion forum. This is not a scientific paper or journal article.

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

#252

Post by philosopher1234 »

cmrdporcupine wrote: post #251
philosopher1234 wrote: post #250

Earlier quoted context omitted.

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

Pretty sure it wasn't "so does everyone else at Google." I challenge you to find that quote. Not at all representative of what I said. Stop casting aspersions on me. I think you might be a little too emotionally attached to Go? I am allowed to have a subjective opinion on Go and voice it in public discussion forum. This is not a scientific paper or journal article.

You're allowed to do whatever you want, as am I. I claim that your comment was unconstructive and paraphrased the meaning of your comment. I didn't learn anything about the weaknesses of Go from reading your comment, I learned that you don't like it and there was a vague suggestion that it is unpopular at google, and that the reason its popular outside of google has to do with cargo culting. But you neglected to express why you thought its weaknesses of go (what are those weaknesses?) that leads to this situation.

I would genuinely like to know what your criticism of the language is, but you haven't offered any. The comment you wrote does not add any clarity to the discussion of Go, in fact I think it takes away clarity by relying on suggestion and avoiding grappling with any details. I think it was not a useful contribution to this thread. I'll leave it at that.

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

#253

Post by AnimalMuppet »

philosopher1234 wrote: post #252
cmrdporcupine wrote: post #251

Earlier quoted context omitted.

Pretty sure it wasn't "so does everyone else at Google." I challenge you to find that quote. Not at all representative of what I said. Stop casting aspersions on me. I think you might be a little too emotionally attached to Go? I am allowed to have a subjective opinion on Go and voice it in public discussion forum. This is not a scientific paper or journal article.

You're allowed to do whatever you want, as am I. I claim that your comment was unconstructive and paraphrased the meaning of your comment. I didn't learn anything about the weaknesses of Go from reading your comment, I learned that you don't like it and there was a vague suggestion that it is unpopular at google, and that the reason its popular outside of google has to do with cargo culting. But you neglected to expr…

cmrdporcupine stated, at least once, that he didn't consider his reasons for disliking Go to be on-topic for this thread. You seem obsessed with trying to pry the reason out of him. He said he's not going to answer; let it go.

If you have to have an answer, he said he's opined on it in the past. Go trawl through his past comments. (Google search might help.)

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

#254

Post by apta »

cpuguy83 wrote: post #240
apta wrote: post #235

Earlier quoted context omitted.

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.

> You can create an exported version of the function

These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims.

I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction

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

#255

Post by JyB »

candiddevmike wrote: post #127

Anecdote of one here, but I think Go's best use case is building monoliths (queue the irony of it being used for a lot of microservice work). The way the language works and the readability it provides really removes a lot of the arguments for breaking apart a monolith, and the performance guarantees it has around parallelism and goroutines make combining your async task processing into your main binary trivial. I'd g…

That's an interesting take. Do you have personal experience that you could share more detail on? Or even more public projects

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

#256

Post by candiddevmike »

JyB wrote: post #255
candiddevmike wrote: post #127

Anecdote of one here, but I think Go's best use case is building monoliths (queue the irony of it being used for a lot of microservice work). The way the language works and the readability it provides really removes a lot of the arguments for breaking apart a monolith, and the performance guarantees it has around parallelism and goroutines make combining your async task processing into your main binary trivial. I'd g…

That's an interesting take. Do you have personal experience that you could share more detail on? Or even more public projects

I would say the most prolific one is Kubernetes. Sure it has some parts broken out (controller manager, scheduler), but the main API server is a pretty big Go monolith.

At a far smaller scale, the SaaS product my company built, Domestica (https://about.domestica.app), is a Go monolith. It has an integrated job/cron queue using PostgreSQL included as well, all within the same binary. This makes it easy for us to distribute it as a Docker image to our users who want a private instance (https://hub.docker.com/r/candiddev/domestica).

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

#257

Post by tmerr »

erik_seaberg wrote: post #228
andykx wrote: post #224

Earlier quoted context omitted.

Would most people actually do that? That example seems like pretty idiomatic Go. I imagine junior developers would write that.

I would typically expect anyBlue := false for _, c in range col { ready, err := c.IsReady() if err != nil { return nil, fmt.Errorf("isReady failed: %v", err) } if !ready { continue } x, err := ConvertToX(c) if err != nil { return nil, fmt.Errorf("convertToX failed: %v", err) } color, err := x.GetColor() if err != nil { return nil, fmt.Errorf("getColor failed: %v", err) } if color == BLUE { anyBlue = true break } } wh…

If IsReady, ConvertToX, and GetColor can return errors then this isn't that far off. But then you're not making an apples to apples comparison. You would have to extend your functional example so that it also handles errors. Unless it already does, and I am missing something.

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

#258

Post by _y5hn »

kovac wrote: post #225
_y5hn wrote: post #221

Earlier quoted context omitted.

What you feel about what you don't understand, isn't really important to anyone else though. Go provides less is more as a feature, but would be invisible unless the dev cared about seeking simplicity and performance.

Go is not simple (conceptually) by any strecth of imagination. Golang has pointers bolted on as if they are a real thing. Like, what's the point of exposing pointers without the pointer arithmetic when modern languages have come up with simpler ways to think about accessing memory? So, as a Go developer are you supposed to understand pointers or not? Similarly with Go routines, people boast about them as if they are…

Go spec is quite short and understandable. The implementation handle quite alot for you, which is not simple, but makes many applications easy to write. Code is fast to write and easy to read. Golang really has 2 types of references, not pointers. I find C and Python slow and tedious to use, and would rather not share memory if I can avoid it, including using pointers (use map instead). It depends what one wants from a language, where golang fills a nice untraditional niche where experience and newcomers can meet. I find Go optimizes more concerns than any other language, which in turn makes it an opinionated balance of several dimensions.

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

#259

Post by aw1621107 »

typical182 wrote: post #217
aw1621107 wrote: post #200

Earlier quoted context omitted.

After digging a bit more, I found a comment from a Discord engineer that seems to clear things up [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. So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon. That being sa…

Based on reading through various posts from Discord people after that blog was posted, my understanding was there was a material gap in time between the last time they tried in earnest to solve the latency issue with Go (with Go 1.10, as in your quote) vs. when they later did the re-write in Rust. It seems during that gap in time, the Go runtime team happened to solve their problem, which was GA in Go 1.12 in Feb 201…

I think it comes down to what "we had made the switch over mid 2019" is supposed to mean. I had interpreted that as being the time the Rust implementation was put into production and the Go implementation retired, with the rewrite starting some time before then, but I don't really have any strong evidence to support that interpretation (and that interpretation doesn't say anything about the actual point at which the rewrite decision was made).

The situation you describe is certainly plausible, though. Shame that the chances of finding out what actually happened are quite low at this point.

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

#260

Post by erik_seaberg »

tmerr wrote: post #257
erik_seaberg wrote: post #228

Earlier quoted context omitted.

I would typically expect anyBlue := false for _, c in range col { ready, err := c.IsReady() if err != nil { return nil, fmt.Errorf("isReady failed: %v", err) } if !ready { continue } x, err := ConvertToX(c) if err != nil { return nil, fmt.Errorf("convertToX failed: %v", err) } color, err := x.GetColor() if err != nil { return nil, fmt.Errorf("getColor failed: %v", err) } if color == BLUE { anyBlue = true break } } wh…

If IsReady, ConvertToX, and GetColor can return errors then this isn't that far off. But then you're not making an apples to apples comparison. You would have to extend your functional example so that it also handles errors. Unless it already does, and I am missing something.

What I wrote should be pretty close to valid Scala, which handles exceptions. I can imagine wanting to skip an isReady failure, which looks like

  col.filter(c => Try(c.isReady).getOrElse(false))
  .map(convertToX).any(_.color == BLUE)
Post reply on HN