4 ms·
I don't see anything wrong with Node's approach to concurrency. It uses IPC which is much more scalable than threads and mutexes. Also, you don't have to use ca
by jondubois 10y ago
I don't see anything wrong with Node's approach to concurrency. It uses IPC which is much more scalable than threads and mutexes. Also, you don't have to use callbacks anymore, now we have Promises and there are tons of libraries that allow you to do reactive programming so you can just wire-up streams of data together in complex sequences.
This article is just inflammatory and illogical.
I think Node.js is one of the best backend engines which was ever created - And I've programmed in everything including AVR Assembly Python, PHP, C#, C/C++, Java and many others. I like Node.js the most.
And yes, you're right, the Node.js community isn't a 'proud' community - We're more interested in constantly improving than sitting there being satisfied with ourselves whilst bashing other tools.
There is no perfect tool/stack; they all have pros and cons. It's all about personal preferences.
- wjagodfrey 10y agoWell said. To everyone responding positively to this article, enjoy your confirmation bias. Have a side of emotional reasoning while you're at it.
- premium-concern 10y agoSometimes it's hard to tell satire from reality, but you gave it away in the end. :-)
- signa11 10y ago> I don't see anything wrong with Node's approach to concurrency. to me, erlang's model seems to be the best one that is around. without a runtime scheduler, message boxes + selective receive etc., i don't really think it is possible to do justice to the whole csp thingy. you can have approximations to it, but that doesn't go very far. for example, in erlang, i can start processes etc. and have them run essentially while(1) { } and nothing really bad happens to other concurrently running threads.