Go hits the concurrency nail on the head • Hacker News Board

Re: Go hits the concurrency nail on the head

#91

Post by [deleted] » Thu, Oct 04, 2018, 6:59 PM UTC

CydeWeys wrote: post #30

mirceal wrote: post #22

Earlier quoted context omitted.

Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many…

I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.

[deleted]

Re: Go hits the concurrency nail on the head

#92

Post by pcwalton » Thu, Oct 04, 2018, 7:01 PM UTC

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 engineer had a patch [1] that unfortunately never landed to add this support in 2013. Windows already has this functionality, via UMS. I would like to see Linux push further on this, because kernel support seems like the right way to improve context switching performance.

2. "Goroutines also have small stacks that can grow at run-time (something thread stacks cannot do)." This is a frequent myth. Thread stacks can do this too, with appropriate runtime support: after all, if they couldn't, then Go couldn't implement stack growth, since Go's runtime is built in userland on top of kernel threads. Stack growth is a feature of the garbage collection infrastructure, not of the concurrency support. You could have stack growth in a 1:1 thread system as well, as long as that system kept the information needed to relocate pointers into the stack.

Goroutines are threads. So the idea the "Go has eliminated the distinction between synchronous and asynchronous code" is only vacuously true, because in Go, everything is synchronous.

Finally, Go doesn't do anything to prevent data races, which are the biggest problem facing concurrent code. It actually makes data races easier than in languages like C++, because it has no concept of const, even as a lint. Race detectors have long existed in C++ as well, at least as far back as Helgrind.

[1]: https://blog.linuxplumbersconf.org/2013/ocw/system/presentat...

Re: Go hits the concurrency nail on the head

#93

Post by geodel » Thu, Oct 04, 2018, 7:01 PM UTC

fulafel wrote: post #84

weberc2 wrote: post #77

Earlier quoted context omitted.

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

Ericsson abandoned Erlang, or Erlang abandoned Ericsson, depending on how you look: Ericsson banned it internally, and shortly afterwards when the Erlang team managed to get it open sourced, they resigned from Ericsson and founded their own Erlang company. (source: http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_e... )

So does Ericsson still use Erlang in their recent network hardware etc?

Re: Go hits the concurrency nail on the head

#94

Post by ngrilly » Thu, Oct 04, 2018, 7:02 PM UTC

nimish wrote: post #44

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…

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 :(

True, but Go and Erlang don't occupy the same niche.

Go is imperative, while Erlang is mostly functional.

Go is AOT (ahead-of-time) compiled, while Erlang runs on a VM.

Go is statically typed, while Erlang is dynamically typed (I know about Dializer).

Go concurrency primitives are designed to coordinate goroutines living in the same process, while Erlang concurrency primitives are designed to coordinate Erlang "processes" living in the Erlang VM or even in multiple Erlang VMs forming a cluster.

Re: Go hits the concurrency nail on the head

#95

Post by rustcharm » Thu, Oct 04, 2018, 7:03 PM UTC

I disagree. You really need "shared nothing" and messages. The only language that really hits the concurrency nail on the head is Erlang, which we use extensively in our business.

Re: Go hits the concurrency nail on the head

#96

Post by matt_m » Thu, Oct 04, 2018, 7:03 PM UTC

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…

Go is also statically typed while Erlang/Clojure are dynamically typed. That seems like another pretty significant difference aside from the syntax.

Re: Go hits the concurrency nail on the head

#97

Post by xor1 » Thu, Oct 04, 2018, 7:03 PM UTC

mirceal wrote: post #22

vvanders wrote: post #4

Earlier quoted context omitted.

I think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades. [1] https://phoenixframework.org/blog/the-road-to-2-million-webs...

Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many…

>Yes. Because mainstream is what you should select for when choosing your tools.

Ease of hiring experienced developers should absolutely be a part of selection criteria, but of course it should not be the only one. What good is it going to do you when you picked Elixir/Scala/Rust over Python/Go/Ruby, you need to hire senior engineers who can hit the ground running ASAP, and you have limited resources/budget?

It's going to be harder to find them (especially if you're not in SF), it's a harder/longer initial learning curve if you hire senior engineers without prior experience, it's going to be harder to find non-seniors, you're going to have to pay more to get what you want...the list goes on.

Re: Go hits the concurrency nail on the head

#98

Post by gjm11 » Thu, Oct 04, 2018, 7:05 PM UTC

dmead wrote: post #43

This picture is a bit rosey, no? Literally the only deadlock I've come across in years has been in go.

What fraction of the concurrent programming you've done over those years has been in Go?

Re: Go hits the concurrency nail on the head

#99

Post by kazinator » Thu, Oct 04, 2018, 7:07 PM UTC

LukeShu wrote: post #34

kazinator wrote: post #7

Earlier quoted context omitted.

Actually it's very easy to avoid data-structure related deadlocks: - avoid holding two locks simultaneously: that guarantees no deadlocks. - if you have to hold several locks, always acquire them in the same order in all scenarios. The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructi…

"avoid holding two locks simultaneously" only guarantees no deadlocks if locks are your only form of inter-thread-blocking. If you have synchronization points or channels/pipes or anything else, that needs to be expanded to include "avoid using a channel while you hold a lock" and similar for every blocking primitive.

That's right; avoid doing anything that could block while holding a lock: acquiring another lock, waiting on a semaphore, and so on.

Note how condition variables have an aspect of this built-in: the wait operation gives up the mutex.

Re: Go hits the concurrency nail on the head

#100

Post by spinningslate » Thu, Oct 04, 2018, 7:08 PM UTC

Don't disagree with the challenges about other languages being equally applicable. My first thought was also "Erlang does it at least as well as Go". Reasonable challenges on whether Erlang (or Elixir/Pony/...) are mainstream though.

For me the more valuable point is not that Go specifically gets it right: it's that async - as implemented in javascript/python/java/c# and so on - is fundamentally wrong. These two quotes get to the heart of it:

>The core idea is that in the asynchronous model we have to mentally note the blocking nature of every function, and this affects where we can call it from.

>The fundamental issue here is that both Python and C++ try to solve this problem on a library level, when it really needs a language runtime solution.

I've said for a while that async as implemented in javascript et al is the "GOTO" of concurrency - and should be considered equally as harmful as Dijkstra's observation on GOTO, for many of the same reasons [0].

[0] https://en.wikipedia.org/wiki/Considered_harmful