This is an appealing train of thought, but it turns out to be very hard to make this pay off, at least in all the concrete situations I've been able to consider

This is an appealing train of thought, but it turns out to be very hard to make this pay off, at least in all the concrete situations I've been able to consider. The reason is subtle: "I/O bound" workloads often only become so when they started out "memory bound." If you've got more memory, you can often buffer or cache your way out of being I/O bound. And squeezing the last few percent out of machine memory is a weakness of the productivity languages' runtimes, because it runs counter to the natural goals of a garbage collector. Consider, say, a database. In its equilibrium state, serving a read-biased workload, the DBMS's ability to use every cotton-picking byte of RAM to cache precious blocks will powerfully determine performance. The workload only really becomes "I/O bound" once you run out of RAM, and a runtime that exacts an X% tax on RAM will become I/O bound that much more quickly. This seems to be an inherent trade-off in the "automatic memory management" paradigm; even Sun's JVM is not immune to this. It's also the right trade-off for a huge majority of code. But it's one of the reasons systems programs in minority languages are driving into a stiff wind.