11–20 of 90 posts
I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.
People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency.
Not that you'd get this from the article.
I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.
I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.
What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)
Earlier quoted context omitted.
I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.
> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)
It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance.
Technically there are tools that will convert, say, Haskell to Javascript so that you can have shared code between a client and server. In practice, I don't know anyone who does that. I'm sure for most it feels like a bit of a hack. So for practical purposes, the only way to share code between the client and server is by using javascript (or coffeescript) on the server-side as well. Node.js IMO is the best server-side javascript engine.
What a bunch of gobbledygook. People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency. Not that you'd get this from the article.
Earlier quoted context omitted.
I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.
> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)
-No mental context switch when working on both ends
-Easier serialization (though JSON is pretty portable...)
-Sharing code
What a bunch of gobbledygook. People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency. Not that you'd get this from the article.
Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...
NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.
What a bunch of gobbledygook. People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency. Not that you'd get this from the article.
Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...
Calling node.js concurrent obscures the important fact under discussion: namely that it won't scale beyond one CPU in a world where 8-core servers are routine.