7 ms·

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-b

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?

samstokes 15y ago
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 think even C++ had one.
- unshift 15y ago
  C++ has asio, now part of boost. 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.
  - jerf 15y ago
    "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.
    - unshift 15y ago
      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.
szany 15y ago
Nested data parallelism: http://www.youtube.com/watch?v=NWSZ4c9yqW8 http://www.youtube.com/watch?v=NWSZ4c9yqW8
jerf 15y ago
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-parallel.html 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/doc/html/Control-Parallel-Strategies.html 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-simon-peyton-jones/js-1434 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.
- 15y ago
fleitz 15y ago
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.
cdavid 15y ago
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.

samstokes 15y ago

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 think even C++ had one.

unshift 15y ago
C++ has asio, now part of boost. 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.
- jerf 15y ago
  "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.
  - unshift 15y ago
    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.

szany 15y ago

Nested data parallelism: http://www.youtube.com/watch?v=NWSZ4c9yqW8 http://www.youtube.com/watch?v=NWSZ4c9yqW8

jerf 15y ago

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-parallel.html 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/doc/html/Control-Parallel-Strategies.html 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-simon-peyton-jones/js-1434 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.

15y ago

fleitz 15y ago

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.

cdavid 15y ago

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.