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