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?
Pretty much any GUI framework ever built, NIO, AIO, .NET eventing framework. All node.js brings to the table is a really verbose way of writing a lambda, it just happens to be a little easier in javascript than other C-derived languages. Want to see non-blocking IO at scale written in C? Go look inside any OS kernel.
Non-blocking IO is not a new concept. Haskell isn't blazing any particularly new trails. It's a refinement of ideas from functional programming, just like javascript is a refinement of ideas from imperative programming. Also, it's not really javascript that made Node.js possible, it's improved javascript execution performance.
It's just a language. Use whatever solves the problem you have in the way you want it solved.
Twisted Python and Ruby's EventMachine would both be examples of evented IO frameworks that predate Node.js's popularity, and possibly even its development.
i have a bit of experience with twisted and must say it's pretty world class. it has great streaming APIs, really convenient APIs for working with processes, in addition to a solid networking library where you can either build your own protocols or use existing ones.
to say "it failed at scale" is ridiculous. i can point to a number of institutions with plenty of twisted code in production, moving hundreds of GB a day of data.
the only reason it would seem "failed" or "obscure" is that node.js has a huge fad aspect to it where people blog about and evangelize it constantly. most things in software don't have a fraction of the hype or exposure but that's not really due to technical shortcomings or lack of use.
"Failed to scale" means that async event-based programming becomes harder too quickly as the program grows in size. Performance isn't the problem, the problem is the program complexity explodes too quickly.
Twisted is world class; the fact that it essentially failed to escape its niche is one of the bits of evidence I submit for saying this style doesn't have some immense reservoir of success left to tap. Twisted basically tapped it, in a nicer language for what it is doing that Javascript is, and it's not enough to take the world by storm, in terms of solving the concurrency problem. Use it if it's the best solution, by all means, though. It's quality stuff.
i don't think anyone thinks it's a solution to the general problem of concurrency. it's an evented framework, much like django is an MVC web framework. use of either library is pretty pedestrian.
twisted made a few innovations (Deferred, @inlineCallbacks, push/pull producer API) but all in all select loops are not new technology.
node is getting way too much credit if you ask me, but i think it's mostly because it's exposed a generally naive class of programmers (javascript coders) to a different paradigm. C programmers have known about select() for the last 30 years.
Perl has so many that a library was built on top to manage abstracting between them, AnyEvent, which unified support for many event-loop based systems, most notably Glib, Event::Lib, and POE, but quite a few others (and IIRC POE actually outcompeted some other contender that is now dead). Ruby has EventMachine (predates Node.js, not that timeframe though). Tcl was simply built around an event loop, so it isn't even meaningful to talk about which library adds it. Python has Twisted and Stackless Python (which has many of the interesting capabilities that Erlang has at a language level), along with libevent and libev bindings. C also has numerous ones, with corresponding bindings in many languages, glib being one big one. gtk is built on glib, but you can get the glib event loop outside of gtk, and there are real things that use it, like the pidgin core, which is not actually dependent on a UI, only glib.
Actually, everybody has libevent and libev bindings. Everybody can get at event-based programming in whatever language they like.
Those are just the highlights. Also, if you're tempted to say "but what about this one library", go check to see if you can find it for Twisted first.
Also, it's worth pointing out that GUIs have been "asynchronous event-based programming" for over 30 years now, and in practice it's hardly any different in programming style than working with Node.js, especially when using a binding to Python, Perl, Tcl, Ruby, etc.
Haskell has one of the few functioning Software Transactional Memorys, and the reason why it works is actually critically based on the nature of Haskell. (Imperative languages have generally been unable to implement them because it turns out to be critical to control effects, and it's just too easy for something to slip in without a type system preventing it.) Haskell has "par": http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/lang-... , section 7.18.4, which is nearly trivial in a pure functional language and a freakishly hairy mess in an imperative language. See also http://hackage.haskell.org/packages/archive/parallel/3.1.0.1... . Data Parallel Haskell is an interesting project in the early stages.
Actually, just watch this video: http://skillsmatter.com/podcast/scala/talk-by-haskell-expert... , which will also (at the end) explain what's interesting about Data Parallel Haskell beyond just "parallel arrays", which has been done; DPH is actually more interesting than that, and also something hard to imagine being implemented in something like Javascript.
Yeah, but.... i mean, it's Perl. EventMachine's HTTP server threw tons of warnings for every request when I used it in early 2010 (and that's actually what drove me to Node in the first place.) Twisted Python is pretty un-pythonic and building a huge webapp in C is usually a mistake.
To me, Node seems like the first (most?) "natural" way of programming in this style, even if the competition pioneered it. Everybody knows Javascript and lots of people haven't taken a look at your other choices, so it seems to nicely fit that gap in the programming language spectrum.
Thanks for showing off the haskell stuff. I really need to get around to learning that language.
Not having much experience with node.js, what makes it more natural than twisted ? I agree on twisted being unpythonic, but most of what I don't like in twisted seems rather fundamental to (explicit) async programming (callbacks everywhere, lack of meaningful stack traces, error handling extremely tedious).
If you get to play the "yeah, but", believe me, I can "Yeah, but it's Javascript" with just as much justification.
Given the choice between Perl and Javascript as it stands in V8, I'll take Perl in a split second. js.next would be a harder choice, but it's not the one I have.
"Twisted Python is pretty un-pythonic"
So what? Node isn't Pythonic either; is that stopping you? It's a great little talking point, but if you try to unpack it into something sensible there's nothing actually there.
The difference is Node has an ecosystem of async 3rd party libs for IO drivers etc. Your evented web server is worthless if your IO (DB, File, REST, ...) is sync.
Just as the difference between Java with the JDK and C(++) without any useful standard lib for application development.
"The difference is Node has an ecosystem of async 3rd party libs for IO drivers etc."
This is also an utterly false and misleading argument. You think these multiple event-based ecosystems were all staffed by drooling idiots who didn't realize that? This isn't some sort of subtle point that can be used as a base of a secret sauce, it's a blindingly-obvious core requirement. They all have drivers for all that sort of thing. Some more than others, but they all have the basics. Many were better stocked with more and higher-quality libraries four years ago than Node.js has now.
This is why I say I hate the Node hype, even as I'm only really ambivalent about Node itself. It's bullshit. It's like Ryan Dahl went into hibernation in 1995, only to pop out again a couple of years ago. It's full of lies about the state of the programming world. Node looks fucking awesome if you uncritically swallow the propaganda packet. Well, gosh, no wonder, it's like a magical 2010-ish library magically showed up in 1995! Node looks "meh" at best, and as I said, heading down a dead-end trail, if you look at where it sits in the real programming landscape in 2011.
No. Perl had no async DBC drivers when I wrote Perl code. Netty does not have async JDBC drivers. But then what do I know. But then what do you know, your reply is essentially fact free.
It would help if you point me, e.g. to the 3rd party async IO drivers (JDBC, Redis, MongoDB, File - I have one for HTTP) for Netty.
I can at least find about 5 event-based frameworks focused on network in python alone without thinking much: medusa is ~ 15 years old, Twisted is > 10 years old, there is tornado (~ 2 years old), event/gevent (not sure about the history here), stackless (not sure about the history, but more than 5 years old).
Unless you are doing long polling, I am not sure I understand the point of using an evented framework (and even then, it could be debated I guess). It is very hard to code a significant and reliable piece of code with it.
Also, do you have any examples of these trails Haskell is blazing?