
EMS: Shared Memory Parallelism for Node.js - lkgnmlkrewmgre
https://github.com/syntheticsemantics/ems
======
khgvljhkb
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).

~~~
lucio
I guess the wordcount process cannot be done with immutable structures? at
least not on the same memory footprint, or at the same speed

~~~
khgvljhkb
What do you mean?

------
m_eiman
It's fairly obvious that this will followed by XMS.

~~~
DiThi
And then you'll have to edit CONFIG.SYS (sorry, I couldn't resist)

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

~~~
s986s
You can do this with child processes or you can help with this issue
[https://github.com/nodejs/node/pull/2133](https://github.com/nodejs/node/pull/2133)

~~~
amelius
Child processes don't allow "structural sharing" (unless using complicated
shared-memory techniques, which have their limitations).

("Structural sharing" is a technique to make immutable data structures more
efficient in time and space).

------
kapv89
Can someone explain how is this EMS thing better than these :
[https://www.npmjs.com/package/webworker-
threads](https://www.npmjs.com/package/webworker-threads) ?

~~~
mchahn
webworkers don't share memory. You have to pass data back and forth.

------
ndesaulniers
Do you need more than atomics to build locking primitives?

~~~
CyberDildonics
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).

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

~~~
paulddraper
Only JS runs in all browsers.

Some people want to write once, run anywhere. Hence JS and Node.js. ( or a
compile-to-js language )

