Twitter’s recent move to Netty brought with it significant performance improvements, highlighting the importance of network and concurrency architecture. Netty looks like a great framework, making the most of what Java provides today – but at heart, Netty must still be based on multithreading. Mysterious problems are therefore expected. What is really needed is for the world to move past multithreading (any day now, please) which is just a terrible concurrency paradigm.
Coroutines are a better idea. You can do that in python now as of 2.5, via enhanced generators. Prior to PEP 342, the idea was first popularized among python fans via the stackless fork. This approach has proven useful for high-throughput networking, but not many other languages support this paradigm.
ECMAScript *almost* added it in version 4 – and how marvelous that would have been! The need is especially poignant in the thread-starved world of browser programming. The pushback came from concerns about interpreter complexity, but that feature isn’t as hard to add to interpreters and compilers as people think.
Imagine making an AJAX call, where the call stack of your calling function is set aside and the thread released for browser use. Once the server responds, your function resumes – and it is as though you never left! Isn’t this just the obvious way to do it? I remember one scenario recently where I needed to solicit user input in the middle of a recursive backtracking algorithm, except – oh yeah, ActionScript can’t. Of course I could and did restructure around this language deficiency (Turing completeness and all) – but shouldn’t we instead be structuring our code in whatever way maximizes algorithmic clarity?
Now all we need to do is get ECMAScript on board. And while we’re at it, why not Java, .Net, and other thread-based langauges? Let’s stop threading, and start generating. All the event-based I/O frameworks we see popping up are fine workarounds in the interim, but let’s address the core language deficiency instead.