Eric Florenzano asks why modern web frameworks insist on a synchronous programming model and gives some answers with possible alternatives. The article is dead on, IMO, but I’m not sold on his conclusion:
We need to look at these alternative implementations like coroutines and lightweight processes, so that we can make asynchronous programming as easy as synchronous programming.
For Ruby, this is all about making Fiber robust and widely available. There was a time when I too thought this would solve all problems by hiding the underlying async model but retaining its benefits. That’s the dream. I don’t believe in it anymore. Having experimented with such an approach on a small team, I’m fairly confident that everybody working on an event-based/async program needs to understand the underlying model or blocking code will inevitably be introduced and destroy everything. And once everyone’s comfy with async, you’ll find that the sync façade is annoying and unhelpful. Embrace it.
Simon Willison throws down a C100K problem for node.js. That’s a tough order for a single machine. To get even close, you’re going to need lots of system tuning way down below node.js.
Joe Damato and Aman Gupta show why and how Ruby (MRI)’s thread implementation sucks. Great presentation with lots of useful examples of using tools like strace and gdb to figure out where a process is spending time. Warning: you will be depressed and embarrassed after reading this if you currently target Ruby MRI.
Aman Gupta and Joe Damato have implemented Fibers for the 1.8.6 and 1.8.7 MRIs. They’re patches now but will hopefully go into a 1.8.8 release. I had a chance to see these guys give a quick talk on their work at a local Ruby meetup — it was a hit.
Good idea. Solve the “concurrency problem” for dynamic/scripting languages and the “language syntax problem” for Erlang, without sacrificing the benefits of either. Someone needs to keep an eye on this.