A Node.js hacker asks what Haskell can do to stay relevant.

[jerf]

Uh... it's very much the other way around. Haskell's building the future of concurrency, even if it isn't going to be "the language" of 2020, and Node.js is a throwback to late-1990s to early-2000s solutions that repeated and consistently failed to work at scale, with no real chance that Node.js is going to escape the same fate any more than the several dozen event-based frameworks based on languages very similar to Javascript before it did. (If the manually-compiled event callbacks, cooperative-multithreading scheduling approach was going to be the Next Big Thing, it would have happened years ago.) It's Node.js that needs to worry about how it's going to "stay relevant" as it walks a dead-end path, not Haskell as it blazes (relatively) new trails.

[technomancy]

> It's Node.js that needs to worry about how it's going to "stay relevant" as it walks a dead-end path

Yes, I believe that was the implied punch-line of the submission. http://mobile.twitter.com/kirindave/status/83252128575004672

[BasDirks]

I'm a big Haskell fan, but lambda-loving academia needs to get off its ass and spent a bit more braincycles on fulfilling Haskell's potential as a web language. Node.js community is simply far more energetic and ballsy. I'm quite confident both Node.js and Haskell are here to stay.

[jhuni]

Haskell isn't building anything. It is just a programming language. It is people that are actually building these things and some languages, such as Haskell, are implementations of them.

[weixiyen]

Just to be clear, by "failed to work at scale" you are specifically referring to the asynchronous I/O codebases being difficult to manage, correct?

[benihana]

Do you have any examples of these late 90s early 00s solutions that consistently failed to work at scale? Can you point me to any of the 'several dozen' event-based frameworks before JavaScript did it? I don't seem to remember these very well, and if Node.js is just a throwback, I'd love to see what it was a throwback of.

Also, do you have any examples of these trails Haskell is blazing?

[gawi]

This is funny. I'm the person having submitted the question on StackOverflow. KirinDave just assumed I was a Node.js hacker (which is absolutely not true!). I really wanted to understand how Haskell is planning to attack the >10k-100k connections problem. The question was just an excuse to talk about the Haskell-way.

Personally, I think Node.js offers a regressive programming model and I'm concerned about too many peoples diving into it. Ryan Dahl is a very smart guy, doing a nice job and is greatly responsible for the success of Node.js. The rumors goes he would have been tempted to do something with Haskell first but he stepped back as he was not familiar enough with GHC. Actually, that not a rumor, that's what he said: http://bostinnovation.com/2011/01/31/node-js-interview-4-que...

The problem with Haskell is that Haskellers are very smart peoples (...smart peoples again!). They became very comfortable with some hard to grasp concepts for programmers having a more conventional pedigree and might underestimate the education effort required in order to attract more programmers. Most of them are not necessarily focused at creating a more accessible language but rather explore new FP concepts (which is great, BTW). Things need to change in university classes first.

So you have potentially hard to maintain callback code on the node.js side and monad/lazyness/FR to master on the Haskell side. Nevertheless, from a skill-improvement point of view, I think the Haskell option is a much better investment.

Back to my Scala book now... :)

[KirinDave]

I did just assume, and I apologize if that is offensive to you. But you have to admit, this title is pretty provocative. ;)

[cageface]

Haskell is a great vehicle for cutting edge language research. What's the rush to push it into production coding? Why not let the better ideas trickle down into more pragmatic languages (Scala) and leave the Haskell implementors free to experiment?

[SlyShy]

Answer: if you know Haskell you don't have to run scared from threading, because threading really isn't so hard.

I've heard Node advocates argue that being limited to a single process isn't a problem for scalability because you can just spin up more Node instances... but that's just threading on a different level. You still run into issues coordinating the instances, but now they are going on in your database instead of in your code.

[mnutt]

If you're eventually going to hit the upper limit of a single machine, have you really gained that much? Eventually you'll have to figure out a way to coordinate between processes, because some will be running on other nodes.

[sharmajai]

http://qconlondon.com/dl/qcon-london-2011/slides/GregoryColl... is about this exactly. He explains why Haskell's green threads are better than Node's callback driven model.

[gregwebs]

The SO question and many of these comments are ridiculous because Haskell has already solved this issue in a much better way. Here is the benchmark: http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-...

Give Haskell 4 cores and it can do 100k (simple) requests per second in a single application. Node can't do as many, and can't scale a single application across cores. And you don't have to do anything to reap this because the Haskell runtime is non-blocking. The only other (relatively common) language that has non-blocking IO built into the runtime is Erlang.

[jessedhillon]

This post affirms for me, yet again, that the people who think Node.js represents a notable, significant improvement over current tools are noobs.

[jinushaun]

I didn't know they were competing. Reminds me of Rails v Django articles.

[mnutt]

Maybe I'm being to generous in reading it, but I took the original question as "I'm familiar with Node and the problems it solves. I'm interested in Haskell; can it solve those same problems?"

[olalonde]

Aren't Rails and Django competing? I'd hope so...