"Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort. It's just that someone else has already gone to this effort. BEAM is an event-based server behind the scenes, with lots of syntactic sugar to make it look multithreaded. The PLT Scheme webserver is another example of this."
This really is not a valid critique. When you get down to it, I/O is going to be interrupt driven. Everything other than the interrupt handlers is just going to be "sugar."
Node.js is the worst of both worlds - all that "significant manual effort" is now pushed into the application logic, and all that it's doing for you is just thinly "papering over" the syscalls.
If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM. Marc Feely really understands the issues with green thread scheduling, continuations, and concurrency.
Erlang has a very simple runtime model - processes basically don't have a stack across invocations (message receives) or a dynamic environment, the only concurrency is in mailboxes, and despite claims of being "soft real-time" there's actually not a lot you can do to influence scheduling policy.
Gambit supports pre-emptive multitasking for green threads, with continuations, exceptions, dynamic-wind, and (optionally inheritable) dynamic environments.
Gambit provides mailboxes, but also locks and condition-variables (with a much richer API than most implementations; usually CVs wake either one or all threads, Gambit has functions for both).
Comments
"Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort. It's just that someone else has already gone to this effort. BEAM is an event-based server behind the scenes, with lots of syntactic sugar to make it look multithreaded. The PLT Scheme webserver is another example of this."
This really is not a valid critique. When you get down to it, I/O is going to be interrupt driven. Everything other than the interrupt handlers is just going to be "sugar."
Node.js is the worst of both worlds - all that "significant manual effort" is now pushed into the application logic, and all that it's doing for you is just thinly "papering over" the syscalls.
If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM. Marc Feely really understands the issues with green thread scheduling, continuations, and concurrency.
all that it's doing for you is just thinly "papering over" the syscalls
But wasn't that the whole point of Node - to expose the lower layer of nonblockingness while still allowing a high level language for everything else?
If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM
That's interesting. What are the distinctive points that make it good?
Erlang has a very simple runtime model - processes basically don't have a stack across invocations (message receives) or a dynamic environment, the only concurrency is in mailboxes, and despite claims of being "soft real-time" there's actually not a lot you can do to influence scheduling policy.
Gambit supports pre-emptive multitasking for green threads, with continuations, exceptions, dynamic-wind, and (optionally inheritable) dynamic environments.
Gambit provides mailboxes, but also locks and condition-variables (with a much richer API than most implementations; usually CVs wake either one or all threads, Gambit has functions for both).
Gambit also has a pretty good story for controlling thread scheduling and task deadlines (see SRFI-21: http://srfi.schemers.org/srfi-21/srfi-21.html).
The manual describes these things pretty well:
http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Thread...