Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hits the concurrency nail on the head

eli.thegreenplace.net

Post reply on HN
Print view View original

121–130 of 318 posts

Re: Go hits the concurrency nail on the head

#121

Post by kureikain »

ken wrote: post #69
virmundi wrote: post #46

Earlier quoted context omitted.

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down " this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe! In the case of Go, I can imagine many of its…

> Backed by major corporation

I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python.

I think the key thing to make Go adopt is because the Docker project and Hashi Corp.

The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams

Re: Go hits the concurrency nail on the head

#122

Post by Groxx »

virmundi wrote: post #46
ken wrote: post #31

> I'm happy to go on record claiming that Go is the mainstream language that gets this really right. And it does so by relying on two key principles in its core design... The unmentioned third principle that it relies on is: "Curly braces, so it looks almost like C if you squint". That's what makes a language "mainstream" these days. It looks like Go is very good at concurrency, but from everything I've read, I don't…

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

You can do this with many VM languages too - you package the VM with the code you want to ship. The VM-wrapper still needs to be built for the target arch (like Go), but the code it runs does not (like Go).

I will absolutely agree though that Go makes this easy, which is quite a large benefit. But it's not in any way the opposite of a VM.

Re: Go hits the concurrency nail on the head

#123

Post by HeyImAlex »

kasey_junk wrote: post #82

Its fairly interesting that this article doesn't mention actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages available today and broadly used (with the possible exception of golang). Frankly, I think the concurrency story is one of the weaknesses of golang. Contrary to what this article says you cannot stop thinking about concurrency in your code…

Just my own anecdote, but I write go and typescript daily and I’d take goroutines and go’s other concurrency primitives over aysync/await any day of the week.

Re: Go hits the concurrency nail on the head

#124

Post by pcwalton »

jadbox wrote: post #120
pcwalton wrote: post #92

Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…

So what's preventing Linux from adopting switchto support? I'd love to see the discussion around it.

Beats me! The author no longer works at Google from what I can tell—emails to him bounced.

I'd love to see 1:1 threading become competitive with M:N for the heaviest workloads. It just plays so much nicer with the outside world than M:N does.

Re: Go hits the concurrency nail on the head

#125

Post by Groxx »

pcwalton wrote: post #92

Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…

>Goroutines are threads

This is a thing I have to continually remind newer engs that are using Go. Goroutines have exactly the same memory observability / race conditions / need for locking/etc as any threaded language. Every race bug that exists in e.g. Java also exists in Go. The only real difference for most code is that it pushes you very hard to use channels directly, as they're the only type-safe option.

There are some neat tricks lower down, e.g. where you don't have to explicitly reserve a thread for most syscalls (but there are caveats there too, which is why runtime.LockOSThread() exists), which are legitimately nice conveniences. But not a whole lot else.

Re: Go hits the concurrency nail on the head

#126

Post by TheDong »

kureikain wrote: post #121
ken wrote: post #69

Earlier quoted context omitted.

That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down " this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe! In the case of Go, I can imagine many of its…

> Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams

You're welcome to your opinion.

Anecdotally, I've heard from many people that Go only took off in China because chinese programmers like google and it was sold as a language by google.

> Google engineers probably favors Java/Python

That's irrelevant. The fact of the matter is that Go has a company backing it and providing a constant stream of well-paid developers and infrastructure. Most small languages can barely afford to have two poorly-paid fulltime developers.

I doubt go would exist if there weren't several people getting paid very large quantities of money working on it.

Re: Go hits the concurrency nail on the head

#127

Post by iainmerrick »

Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications.

This is just Apple's Grand Central Dispatch model, or the event loops used internally in Chromium. It's not complicated at all, it's a very practical and productive approach.

Re: Go hits the concurrency nail on the head

#129

Post by accnumnplus1 »

For me, "great tools like the race detector" sums up the article - the detector is fallible, and although every point in the article has some validity, they also could all be argued against, and the result is a bit of a house of cards. So for me, Go at work by order, Erlang at home by choice.

Re: Go hits the concurrency nail on the head

#130

Post by TheDong »

weberc2 wrote: post #77
nimish wrote: post #44

Earlier quoted context omitted.

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(

> full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcs…

> There is a small team at Google that work on the language

How many languages are lucky enough to have paid developers working on them?

Many languages have been labours of love with 1 developer getting paid, at best, pennies or doing it on the side.

I think there's a reasonable middle ground where you can claim "Go made good choices, but it also wouldn't exist as it does nor be as popular without google throwing money at its developers and without the brand association"

For example, the D programming language was wonderfully made and had many great features, but it never got all that far, in part because "Built by Mars" isn't as good as "Built by Google".

Sure, Go didn't just win by default because google was there (Dart is a good proof that Google doesn't instantly make languages succeed), but I'm certain having their backing and name association sure didn't hurt.

Post reply on HN