Go hits the concurrency nail on the head
Go concurrency <i>is</i> just threads. It's a particularly idiosyncratic userland implementation of them.<p>There are two claims here I'd like to unpack further:<p>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.<p>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 <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 "Go has eliminated the distinction between synchronous and asynchronous code" is only vacuously true, because in Go, everything is synchronous.<p>Finally, Go doesn'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://blog.linuxplumbersconf.org/2013/ocw/system/presentations/1653/original/LPC%20-%20User%20Threading.pdf" rel="nofollow">https://blog.linuxplumbersconf.org/2013/ocw/system/presentat...</a>