One of the interesting things about this to me is how this argues for Stackless Python (and likely Erlang and others, though I'm not yet well enough versed in Erlang to say) as a way to think about problems, not just -- or even primarily -- a solution for getting performance out of increasingly parallel machines.(1) Over time, it's become increasingly apparent to me how much I would love green threads (implemented with channels, etc.) in order to write software the communicates with other processes via blocking network calls. Being able to write one function that sends requests and receives the results as a normal function call, rather than writing handlers for each message and separating the logic out among them, would be a very powerful tool to have, though I'm sure there are many other places where logically concurrent designs would be simpler than the more serial designs I often use today.
(1) I know Stackless doesn't actually help with hardware parallelism, outside of being able to possibly pickle and transfer threadlets between processes, but a lot of people come to Stackless looking for a solution to this problem.
3 comments
[ 5.3 ms ] story [ 14.7 ms ] thread(1) I know Stackless doesn't actually help with hardware parallelism, outside of being able to possibly pickle and transfer threadlets between processes, but a lot of people come to Stackless looking for a solution to this problem.