That said, though, what separates the "men from the Erlangs" is that in Tcl, Ruby, Python, Javascript, and company, "never block the reactor" is the name of the game, you can't do a while { 1 } { something } in your event handler or it will wedge the whole thing.
In Erlang, thanks to its built in scheduler, you can.
In Erlang (or a similar multiprocess / actor-based system) you just kill the computation you want to stop. It's up to the killed side (or their supervisor) to know how to handle it - but it doesn't happen during the next computation loop, or when it's convenient - it handles the condition now.
[1] http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/37509...
Essentially what you're saying is that Erlang allows you to make idiotic mistakes?
Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy.
Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason.
You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around cooperative multitasking? Seriously?
I don't want anything else to decide what order my code runs. I want it to run in the order I decide.
Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way.
Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.
Event-based async programming is a hack around language weaknesses and is a strict subset of Erlang's capabilities, in that anything you could write in those frameworks you can write in Erlang. Yes, including "knowing when things execute". In fact I'd say you get more control because you have more choices; you don't have to lock things up if you want to actually run a computation of some sort.
I suggest you spend some quality time with http://www.erlang.org/doc/design_principles/users_guide.html . You can stop at the "included applications" chapter. Erlang is a friend to event-based stuff, after all, it just handles it naturally, without you having to do the scheduling unless you want to.
You can be 100% sure that it won't suddenly stop executing here, and jump over to some totally disconnected bit of code for a while, then jump back.
You don't have to worry about a whole class of bugs which take up weeks/months of peoples time.
Not sure what you mean @ timers, I was really talking about async/event driven in general. Timers seem like an implementation specific detail on top of that. I haven't really seen any issues myself there :/
I reiterate, you need to spend some quality time with Erlang. This time I recommend http://erlang.org/download/erlang-book-part1.pdf ; Erlang has some powerful answers to those "whole class of bugs".
(Actually, not being aware of that does rather make sense of the rest of your views. I have first-hand experience that Erlang really does make those problems go away; I like to say that Erlang takes concurrent programming from an exponential problem to a polynomial one. It still isn't "trivial" and I don't know that it ever can be, but it makes it so a human can do it.)
And I guess you also want to manage all your memory yourself?
Throwing your code at a compiler/CPU and saying "Here! you decide what order to execute this in", means I have to write MORE code to deal with that.
eg asyc/event programming => less code, less complexity, more efficient
Managing memory yourself would mean writing more code and more complexity.
So it's comparing apples to inverse apples.
case recv(10, 5) in
timeout -> handle_this_and_throw
data -> do_something(data)
In an event based scenario:
def got_some(data):
buffer += data
switch(current_processing_state):
case state1:
buffer = try_to_handle(buffer)
case state2:
....
I see more code and more complexity in event style. Care to provide some counter-example? (and I'm not saying it's not possible - just haven't really seen one yet)
On event, do some big, long calculation.
Why should you need to write the code differently from that? It's nice that the language/environment handles things for you, rather than manually dividing things up into little chunks.
Show a calculator.
Why should you need to write the code to do each individual part of the calculator?
I disagree, dividing up the work yourself into chunks means you retain complete control of when your code executes. That actually decreases the complexity of your code, since you know when everything will execute.