Seems like there are couple things going on here. Accusation that asynchronous implementations in all languages are problematic, with which I don't think anyone would disagree. Suggestion that threads are way better than other asynchronous implementations. I don't agree that makes things better or somehow different. You still have disjointed code. I would add this as a third to Fowler's famous quote about two hard things (cache invalidation and naming things).
> Suggestion that threads are way better than other asynchronous implementations.
I don't think that's true. The author mentions several languages that use different solutions:
* Java uses threads
* Lua and Ruby use cooperative multitasking with coroutines and fibers, respectively
* Go uses goroutines, which are coroutines multiplexed onto threads
There are definitely similarities, but not all are threads. The common element is that each solution involves keeping separate call stacks. (The author mentions this too.)
> You still have disjointed code.
I disagree. In Go, I can write an HTTP server that never uses the "go" keyword, yet it's still concurrent. This is because the net/http package handles the goroutines for me. With Node, I have to use callbacks no matter what.
These are all under the general term threading. You still have to pass messages or set up semaphores to use them. The code is still separated between main and sub/worker/thread.
> Go HTTP server
Every HTTP server lib handles requests in this way.
You cannot write an HTTP client, however, without explicit asynchronous code like callbacks, threads, or what have you.
3 comments
[ 2.8 ms ] story [ 20.4 ms ] threadI don't think that's true. The author mentions several languages that use different solutions:
* Java uses threads
* Lua and Ruby use cooperative multitasking with coroutines and fibers, respectively
* Go uses goroutines, which are coroutines multiplexed onto threads
There are definitely similarities, but not all are threads. The common element is that each solution involves keeping separate call stacks. (The author mentions this too.)
> You still have disjointed code.
I disagree. In Go, I can write an HTTP server that never uses the "go" keyword, yet it's still concurrent. This is because the net/http package handles the goroutines for me. With Node, I have to use callbacks no matter what.
These are all under the general term threading. You still have to pass messages or set up semaphores to use them. The code is still separated between main and sub/worker/thread.
> Go HTTP server
Every HTTP server lib handles requests in this way.
You cannot write an HTTP client, however, without explicit asynchronous code like callbacks, threads, or what have you.