New case studies about Google’s use of Go

Post by jayd16 » Fri, Aug 28, 2020, 12:22 AM UTC

eweise wrote: post #178

jayd16 wrote: post #170

Earlier quoted context omitted.

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.

Post by Guthur » Fri, Aug 28, 2020, 12:27 AM UTC

somethingwitty1 wrote: post #159

kevinmgranger wrote: post #115

Earlier quoted context omitted.

map/filter and sum types are not about "fun", they're about correctness and expressiveness. map/filter and their equivalent loops are both perfectly readable, but the latter involves more boilerplate.

And I'd disagree. Numerous engineers of differing skill levels (what I deal with day to day), struggle significantly when map/filter are added into the mix. And we may say "get better engineers", but we don't have that ability. We have to write code that is maintainable for the engineers we have and can get (and the ones coming in the future).

Post by solidasparagus » Fri, Aug 28, 2020, 12:39 AM UTC

erik_seaberg wrote: post #176

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.

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.

  for i, c in range col {
    if c.isReady && convertToX(c).color == "BLUE":
      return True
  }

Post by kjksf » Fri, Aug 28, 2020, 12:44 AM UTC

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.

Post by mas3god » Fri, Aug 28, 2020, 1:12 AM UTC

geodel wrote: post #151

Spivak wrote: post #140

Earlier quoted context omitted.

But they’re specifically talking about a server component here. Using Electron on the client doesn’t magically make their need for a high performance backend disappear. They’re still having to make all those clients work and deliver voice chat to millions of simultaneous users.

Yes of course they are. Further I understand the "strategic decisions", "markets have spoken" , "faster feature due to single codebase" justifications to Electron usage. To me it just feels like saying we care about our servers meanwhile users can eat crap.