Go hits the concurrency nail on the head

Go concurrency <i>is</i> just threads. It&#x27;s a particularly idiosyncratic userland implementation of them.<p>There are two claims here I&#x27;d like to unpack further:<p>1. &quot;I&#x27;ve measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time.&quot; 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.<p>2. &quot;Goroutines also have small stacks that can grow at run-time (something thread stacks cannot do).&quot; This is a frequent myth. Thread stacks can do this too, with appropriate runtime support: after all, if they couldn&#x27;t, then Go couldn&#x27;t implement stack growth, since Go&#x27;s runtime is built in userland on top of kernel threads. Stack growth is a feature of the <i>garbage collection infrastructure</i>, 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.<p>Goroutines <i>are</i> threads. So the idea the &quot;Go has eliminated the distinction between synchronous and asynchronous code&quot; is only vacuously true, because in Go, everything is synchronous.<p>Finally, Go doesn&#x27;t do anything to prevent data races, which are the biggest problem facing concurrent code. It actually makes data races <i>easier</i> 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.<p>[1]: <a href="https:&#x2F;&#x2F;blog.linuxplumbersconf.org&#x2F;2013&#x2F;ocw&#x2F;system&#x2F;presentations&#x2F;1653&#x2F;original&#x2F;LPC%20-%20User%20Threading.pdf" rel="nofollow">https:&#x2F;&#x2F;blog.linuxplumbersconf.org&#x2F;2013&#x2F;ocw&#x2F;system&#x2F;presentat...</a>

&gt; I&#x27;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...<p>The unmentioned third principle that it relies on is: &quot;Curly braces, so it looks almost like C if you squint&quot;. That&#x27;s what makes a language &quot;mainstream&quot; these days.<p>It looks like Go is very good at concurrency, but from everything I&#x27;ve read, I don&#x27;t see how it&#x27;s any better than Erlang or Clojure. The only controversial part of Eli&#x27;s claim is the implication that other languages that get concurrency right aren&#x27;t &quot;mainstream&quot;. That&#x27;s not a well-defined term and so naturally this is going to irk many people.<p>Perhaps the title would have been more accurate as &quot;Go hits the concurrency nail on the head, using the hammer of K&amp;R style&quot;. :-)

I think the author might be overstating how unique Go’s position is in terms of making concurrency easier. Haskell has the best concurrency story of any language I’ve used. Super lightweight green threads, simple concurrency primitives like MVar and STM, good performance (possibly requiring tweaks, but not bad out of the box). Referential transparency (by which I basically mean immutable data) makes sharing data across threads much easier and in some cases more performant by allowing you to avoid copying. Plus, you have a type system which makes it much easier to reason about your code.<p>All that being said, I haven’t written Go and can’t compare the two. Also, Haskell doesn’t support the actor&#x2F;message passing model out of the box (although libraries exist for it) or prevent deadlocks (although the immutability helps a great deal here). BEAM languages, clojure, rust, pony and others all have their strengths here — again, this doesn’t discredit the article at all but the idea that Go is the clear winner is debatable.

According to the author Go make concurrent programming &quot;the best experience, by far, compared to other popular programming languages today.&quot;<p>I beg to differ. I fail to see why I should choose Go over Elixir&#x2F;Erlang for concurrency. Elixir&#x27;s cuncurrency mechanisms are at least as good — and I would argue better — than Go&#x27;s, and Elixir as a language has an expressiveness that Go lacks.

&gt; <i>Programming with threads is hard - it&#x27;s hard to synchronize access to data structures without causing deadlocks; it&#x27;s hard to reason about multiple threads accessing the same data, it&#x27;s hard to choose the right locking granularity, etc.</i><p>That&#x27;s a list of problems that are specific to mutable state that is shared among threads.<p>As the old saying goes, &quot;If it hurts, don&#x27;t do it.&quot;<p>We&#x27;ve had ways of doing multithreaded code that are easier to reason about for <i>decades</i>. They really do work quite well. Why people doggedly insist on pretending they don&#x27;t exist is a perennial mystery to me. Even if your programming language wasn&#x27;t kind enough to include a better concurrency model in its standard library, there are always third-party libraries.<p>I realize my experience isn&#x27;t universal, but, personally, I&#x27;ve discovered that there&#x27;s precisely one scenario where I ever need to resort to code that involves mutexes: When the business requirements and the performance profiler have conspired to kidnap my children and hold them for ransom.

Its fairly interesting that this article doesn&#x27;t mention actors, futures&#x2F;promises and async&#x2F;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).<p>Frankly, I think the concurrency story is one of the <i>weaknesses</i> of golang. Contrary to what this article says you cannot stop thinking about concurrency in your code in golang like you can in some of the more avante garde concurrency models (STM) and it doesn&#x27;t provide nearly the sophistication in type or post build checking of other languages.

Don&#x27;t disagree with the challenges about other languages being equally applicable. My first thought was also &quot;Erlang does it at least as well as Go&quot;. Reasonable challenges on whether Erlang (or Elixir&#x2F;Pony&#x2F;...) are mainstream though.<p>For me the more valuable point is not that Go specifically gets it right: it&#x27;s that async - as implemented in javascript&#x2F;python&#x2F;java&#x2F;c# and so on - is fundamentally wrong. These two quotes get to the heart of it:<p>&gt;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.<p>&gt;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.<p>I&#x27;ve said for a while that async as implemented in javascript et al is the &quot;GOTO&quot; of concurrency - and should be considered equally as harmful as Dijkstra&#x27;s observation on GOTO, for many of the same reasons [0].<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Considered_harmful" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Considered_harmful</a>

Do people really find CSP a good approach to concurrency? I&#x27;ve always thought that channels were a relatively poor choice of fundamental primitive -- channel-based concurrency is tricky to get right and not very composable.<p>Most viable concurrency primitives are in some sense equivalent (you can build condition variables out of channels and vice-versa, say) but that doesn&#x27;t mean they&#x27;re equally good.<p>Java has per-object &quot;synchronized&quot; and &quot;notify&quot; as its core constructs, but it&#x27;s a bad idea to use those directly for day-to-day concurrency tasks. Much better to use library classes like ThreadPoolExecutor and Future.<p>In Go, do you tend to use channels directly, or do you use higher-level wrappers?

Regarding one of the last comments, I&#x27;d say the two biggest reasons for using Node over Go, at least initially. Prototyping speed, and a stronger connection to a web front-end. I&#x27;ve really not seen any other language&#x2F;platform work faster for developing a huge variety of implementation details than JS&#x2F;Node. IT&#x27;s a really good balance of performance, flexibility and ease of development.<p>Is it a Panacea? Of course not. That said, I think that starting more monolithic an breaking pieces off as needed is a strong approach, best started with Node. From there, you want different pipelines&#x2F;processes&#x2F;queues&#x2F;workers in other platforms, great. Write that piece in go+grpc and call it from your api endpoint server.<p>So many times I see devs want to go the optimal X, without even considering if &quot;optimal&quot; is needed, and if it&#x27;s prudent to start with.

For me, &quot;great tools like the race detector&quot; 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.

<i>Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications.</i><p>This is just Apple&#x27;s Grand Central Dispatch model, or the event loops used internally in Chromium. It&#x27;s not complicated at all, it&#x27;s a very practical and productive approach.

Or you could just use the Actor model, which I like much better than CSP. (Or at least I think I&#x27;ll like it better when I finally understand it.)

&gt; Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications.<p>Correct me if I&#x27;m wrong, but doesn&#x27;t basically every UI framework from the last 20 years do exactly this?

&gt; Proper use of channels removes the need for more explicit locking<p>If you&#x27;re lucky. Sharing mutable state is unsafe by default (map writes can crash!) yet very common and the language doesn&#x27;t help you avoid it. A good language for concurrency would also make it easy to switch between sync and async method calls; the trouble with channels is they don&#x27;t support passing errors and panics without rewriting everything to wrap them in a pseudo-generic struct.

Leave aside the extremely interesting engineer behind th go scheduler and goroutine.<p>The abstraction that goroutine provides is a simple, indipendent, isolated unit of execution.<p>You start it, and that is all you can do with it.<p>No way to set priorities, decided when to stop it or inspect it.<p>After the goroutine start the only interface that you get is a channel where to push and pop stuff from. Which is just too limited consider the complete lack of genetics.<p>It is really the best we can come up with?

Apparently there is a C library for green (Go-like) threads called &quot;libdill&quot; or &quot;libmill&quot;.

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

What other languages&#x2F;platforms are out there that are as good with concurrency as Go?

&gt; Programming with threads is hard - it&#x27;s hard to synchronize access to data structures without causing deadlocks; it&#x27;s hard to reason about multiple threads accessing the same data, it&#x27;s hard to choose the right locking granularity, etc.<p>It&#x27;s almost as if we need a language that has a focus on data races, concurrency and fearless threading.

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