Live data from Hacker News

Node.js is Backwards

blog.ankurgoyal.com

41–50 of 90 posts

Re: Node.js is Backwards

#41
post #18

Earlier quoted context omitted.

Off the top of my head benefits: -No mental context switch when working on both ends -Easier serialization (though JSON is pretty portable...) -Sharing code They aren't exclusive to Node and JS, but browsers run JS and will continue to for the foreseeable future. Since the front end can't budge its language at the moment, the back end has to.

I see the "sharing code" claim a lot but I haven't really seen it substantiated. Seems like you write a few little functions but it's not like you sharing the same framework which would be the real benefit.

> Seems like you write a few little functions...

Seriously? A very common problem in web apps is validation logic is usually duplicated in JS and Server side language.

Node allows the same logic to be used in both cases. These are not a 'few little functions'. Validation is a central part of most business applications.

Given the potential to template html with javascript, and to code exclusively in javascript. You could end up with webapps written entirely in one language.

Whether that is a good thing or not remains to be seen, but it is something that we should pay attention to.

Re: Node.js is Backwards

#42
post #17

Earlier quoted context omitted.

Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. 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.

Since the early days of node there has been a proposal to dispatch tasks via the WebWorker API, with a callback - as is currently done for calls to OS subsystems. Sounds like that would be a great way of dispatching CPU intensive tasks without breaking the semantics of Node. What happened to this?

Re: Node.js is Backwards

#43
post #23
post #20

Earlier quoted context omitted.

That seems too nitpicky to me. You can use those definitions if you like, but it's not the common usage. To most programmers those terms are synonyms. In my experience, people trying to be precise about architectures like node.js use the term "asynchronous" and not "concurrent". 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 s…

The distinction between parallelism and concurrency is extremely important. The guys who wrote Real World Haskell did a good job of explaining it here http://book.realworldhaskell.org/read/concurrent-and-multico... (explanation has nothing to do with Haskell). In essence, concurrency has to do with systemsy stuff- how to do things that might overlap without causing problems (race conditions). On the other hand, paral…

You're arguing semantics: about words, not meaning. My point wasn't that this isn't interesting, but that the jargon you are using (and that book is using, for that matter) is revisionist and confusing. That's just not what "concurrency" means to most working programmers, who have used it for decades to talk about (ahem) "systemy stuff".

Rewriting language via blog posts doesn't work (c.f. "hacker"). Doing so as a way to, frankly, cover up a huge design flaw in your favorite library just seems dumb to me.

Re: Node.js is Backwards

#44

> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s. Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.

Erlang, and other similar efforts like Haskell's forkIO and Python's eventlet/gevent, are also built upon the same fundamentals as libev (and some actually just use libev). But using libev in the way that Node.js does boils down to user-space threads with cooperative scheduling (you yield control every time you make a blocking I/O call). The abstractions that Erlang/Haskell/Python provide let you program in the familiar synchronous, threaded style while retaining the performance advantages of an explicit (e)polling server.

Ted Dziuba explained this well for Python http://teddziuba.com/2010/02/eventlet-asynchronous-io-for-g....

Re: Node.js is Backwards

#45

Earlier quoted context omitted.

I love Node for many things, but I agree with this sentiment. At work, every time we undertake a project in Node, it just doesn't work at scale, and it has to get re-implemented in Erlang. A lot of this is for personnel reasons. To all of us Node is a neat new toy, where a few engineers are Erlang wizards. If Node crashes we don't have any experience debugging it. If it locks up there's little intuition why. Can peop…

plurk

Not large and not Node.

Re: Node.js is Backwards

#46
Does anyone know how well Scala can handle the requirements of a typical Node.js project? IE, thousands of network connections and rather light CPU load overall? Can Scala be a Node.js or Erlang replacement?

Re: Node.js is Backwards

#48

My node.js project spreads all node.js i/o across multiple node processes ( in machine, network, or browser ) and creates a distributed EventEmitter across all nodes. https://github.com/Marak/hook.io

Where were you 4 months ago?

Re: Node.js is Backwards

#50
post #46

Does anyone know how well Scala can handle the requirements of a typical Node.js project? IE, thousands of network connections and rather light CPU load overall? Can Scala be a Node.js or Erlang replacement?

look at some of the Akka deploys

http://stackoverflow.com/questions/4493001/good-use-case-for...

http://fornax-sculptor.blogspot.com/2010/08/eda-akka-as-even...

(minimal code example)

http://groups.google.com/group/akka-user/browse_thread/threa...

There's probably similar cookbook examples and benchmark/ overhead per process measurements for F# MailboxProcessors, if you're curious

Post reply on HN