Can we have immutable datastructures in a multithreaded NodeJs please? It is simple to implement (because immutable), and would solve a lot of problems.
NodeJS works nicely with nonblocking IO, except what most people seem to forget is that the CPU is a resource too, which is still being blocked by NodeJS when handling any event. Multithreading would help alleviate this.
I'd rather have immutable data, and no shared state in concurrent apps, but to each and their own.
Just remember that there is no big conceptual difference between blocking and locking, which is what you end up doing when having shared mutable state.
Recommending anyone to check out CSP (like in Go & Clojure/script (the latter also with immutable data)) or Actors (like in Erlang, Elixir).
> Just remember that there is no big conceptual difference between blocking and locking, which is what you end up doing when having shared mutable state.
Conceptually, yes, but the incredibly low overhead of CPU atomics compared to message passing (especially on x86) mean that theory and practice are very different.
Yes and no. You can build concurrency with just atomics and it will work. If you design the architecture of your program well it can be incredibly fast. Atomics on Intel processors at least are amazingly fast.
Mutexes though have a special property in that when a thread waits for a mutex to be unlocked, the processor can idle (this is all Intel knowledge).
Why not just use Elixir to begin with? Ok, Node existed before Elixir, but erlang has been around a long time.
It seems to me that engineering has become very cargo-cultish. "Lets use node cause we already know javascript" seems to be an argument that people who never learned Java or C/C++/Objective-C or Go or even Python or Ruby would make. Ok, there's a lot of those people... now they are stuck in a monolithic (eg non-distributed) system and dealign with scaling problems.
I'n not saying Erlang is always the right answer (I'm a fan of Go at the moment)... just that there's too much hopping-on-the-bandwagon based on seemingly a lack of awareness of the technology that's out there.
Imagine if all the effort making node work had been put into existing choices.
17 comments
[ 2.9 ms ] story [ 64.3 ms ] threadNodeJS works nicely with nonblocking IO, except what most people seem to forget is that the CPU is a resource too, which is still being blocked by NodeJS when handling any event. Multithreading would help alleviate this.
("Structural sharing" is a technique to make immutable data structures more efficient in time and space).
Just remember that there is no big conceptual difference between blocking and locking, which is what you end up doing when having shared mutable state.
Recommending anyone to check out CSP (like in Go & Clojure/script (the latter also with immutable data)) or Actors (like in Erlang, Elixir).
Conceptually, yes, but the incredibly low overhead of CPU atomics compared to message passing (especially on x86) mean that theory and practice are very different.
And the classic KiranDave/Aphyr vs Ryah thread on "NodeJs Concurrency" https://news.ycombinator.com/item?id=4306241
Mutexes though have a special property in that when a thread waits for a mutex to be unlocked, the processor can idle (this is all Intel knowledge).
It seems to me that engineering has become very cargo-cultish. "Lets use node cause we already know javascript" seems to be an argument that people who never learned Java or C/C++/Objective-C or Go or even Python or Ruby would make. Ok, there's a lot of those people... now they are stuck in a monolithic (eg non-distributed) system and dealign with scaling problems.
I'n not saying Erlang is always the right answer (I'm a fan of Go at the moment)... just that there's too much hopping-on-the-bandwagon based on seemingly a lack of awareness of the technology that's out there.
Imagine if all the effort making node work had been put into existing choices.
Some people want to write once, run anywhere. Hence JS and Node.js. ( or a compile-to-js language )