Hacker News new | comments | show | ask | jobs | submit login

"it is a good tool for those situations where my other choice would have been to write a massively scalable, non-blocking C program."

Agreed. I'd take a Node.js implementation over straight C any day.

"On the flip side, building massively scalable systems based on blocking IO"

Please remember that's an implicit false dichotomy. "Blocking" has to do with the runtime and the VM, not the visual appearance of the programming language syntax. Erlang is non-blocking, but it is also structured (and functional). In fact, by my personal standards Node.js is still a blocking language; you have to jump through hoops to get non-blocking behavior and you only get it when you ask for it. In Erlang or Haskell, you simply get it. Go ahead and do a lengthy math computation if you'd like. Take several minutes. You won't block anything else in the meantime. And you don't have to manually break the computation up yourself. Just do it.

I say Node is stepping back 20 years not because it feels primitive compared to C#, but because it feels primitive compared to the "really existing, I use it in production code" Erlang runtime. Also Haskell, except I can't say I use that in production code. And probably Go (still waiting for someone to confirm), and Stackless Python, and several other things.

The real reason I speak up so often on Node.js articles is not that I hate Node.js, it is that I hate the hype because it is shot through with falsehoods, which I'm rapidly upgrading to "lies" as the same blatant falsehoods continue to get around without the community fixing them. Your alternative is not async event based or synchronous; there's a third option where the async is managed by the compiler and runtime and it works. In fact it's Node.js that has to catch up to even the previously existing async frameworks, and Erlang is simply miles beyond Node.js in every way, except it isn't Javascript. (Which I freely admit is a problem. Erlang-the-language could stand to be improved, even as it is hard to borderline impossible to match the total environment.)

(If you know the choice exists and you don't choose it for some reason, hey, great. Like I said in my first message above, I've got my own async-event based program I have to maintain, and I'm the original author, it was my choice, because when I took all the issues into account, it was the right choice. But you ought to choose with an understanding of the full picture and all the relevant choices, and understand all the tradeoffs, not because you think that async event-based programming is better than everything else at everything. It's got some really serious drawbacks, and there are really-existing, production-quality, "web-scale" things that can be used that do not have those drawbacks.)

I can certainly see your point, and I am aware that I am playing a little fast and loose with some of the terminology around blocking vs non-blocking. To be precise, in node's case, it presents a consistent, callback based API to non-blocking IO. Given that that API is reflected exclusively in JavaScript the language, this has impacts the style and appearance of Node programs. The resultant style is imprecisely referred to as asynchronous, non-blocking, etc.

Using Erlang vs Node on my current project was a serious consideration. It is well thought out and its message passing and lightweight process based design is more evolved than anything node has or likely will have. It's also Erlang and I have found productively programming in it to be incomprehensible. Maybe its a personal problem, but it is what it is. Ditto for Haskell. I was surprised to find that my brain didn't bend that way.

There's always Scala/Java with Akka as a way to get both the actor model and a "more c-style" language. (http://akka.io/)

Absolutely agreed on the hype, btw - When something gets a lot of hype I generally look at it sideways, node included.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact