Perhaps it is taking away a "feature" in some senses, but in my view it is taking the logical step not allowing concurrent access to preempt during execution. I often want the current value that has changed after the original context is changed by an asynchronous task (IP addresses of internal servers changing while a script was running came up today).
There is no way preempting access / memory contention is a feature, but Clojure avoids this with somewhat immutable state which can make keeping up to date values painful, although I may not be experienced enough to state much about Clojure.
For web services such as ours where we have values changing underneath us it is elegant that we keep a value the same through a single flow of control (until the stack unwinds). Even if it is incorrect for one part of the task as a whole, it is predictable where the values can change and dealing with errors from pointing to the wrong object / value is trivial compared to most race conditions (yes, node does those before anyone jumps in).
The environment here is key though. Node was built as a single threaded event loop. All the bindings for node / libraries for node expect this. Libgmp's love of aborting threads after a process gives it a wrong value is a good example of where the single threaded environment fights the threaded model, and the same problems of expecting threads is apparent in many programming environments (.Net Http stack I'm looking at you).
So in many ways: Node does not give you something that cannot be done in other environments; but, in other environments there is a lot of existing code that encourages thread usage. Doing something in twisted or the like proved difficult once I needed libraries that had been written expecting threads. The same is true in Node, but I can be confident that good libraries / bindings for Node provide things that expect to work in a single threaded event loop. And I like the command queue / event loop / actor based / reactive / whatever you want to call it. I like it more than anything due to the lack of concurrent edits, but allowing a lot of mutability at the same time.
By giving a shared in-memory resource for the current state of an object that is not mutated from other threads during a single stack build / teardown. Concurrent access in threads requires locking the object until it is in a determinate state, while in Node you are guaranteed the state until the stack unwinds.
For me it is. However i tend to just use in-memory caches instead of a cache server, which may suffer the same issue. For standard websites, this is a non-issue for CRUD, for task/activity based sites that can have long lived tasks that persist after a request this is very important.
When working with requests that share resources via web frameworks that deal with threads, the large consensus is to put the resource into an external managed resource. This external resource such as a database will manage the locking for you to prevent write conflicts, however, when caching values for complex interaction beyond CRUD you may have update conflicts where a new request has an in memory copy of an outdated resource. This is where the problem lies.
Indeed not, but Erlang is Erlang, Hook.io is Hook.io, and Trolls are Trolls. More perspective on opinions would be helpful to evolving away from problems you see, and/or for the use of understanding your comment.
Hey all, just wanted to chime in about us using this at Nodejitsu. Hook.io makes it much easier to have a huge mesh network of drones for us and greatly simplified our management code for child processes on our stack. If you are looking for an easy way to have a mesh network or a master/slave network Hook.io will be great.
As for personal use, Hook.io is amazing since it is like a mesh network and IPC event bus put together. I create modules, a way of using deamons supporting features through hooks makes life easier and allows them to be services kept alive out of my process.