On Ousterhout ’s Dichotomy Oct 6, 2024
Why are there so many programming languages? One of the driving reasons for this is that some languages tend to produce fast code, but are a bit of a pain to use (C++), while others are a breeze to write, but run somewhat slow (Python). Depending on the ratio of CPUs to programmers, one or the other might be relatively more important.
But can ’t we just, like, implement a universal language that is convenient but slowish by default, but allows an expert programmer to drop to a lower, more performant but harder register? I think there were many attempts at this, and they didn ’t quite work out.
The natural way to go about this is to start from the high-level side. Build a high-level featureful language with large runtime, and then provide granular opt outs of specific runtime facilities. Two great examples here are C# and D. And the most famous example of this paradigm is Python, with “rewrite slow parts in C ” mantra.
It seems to me that such an approach can indeed solve the “easy to use ” part of the dichotomy, but doesn ’t quite work as promised for “runs fast ” one. And here ’s the reason. For performance, what matters is not so much the code that ’s executed, but rather the layout of objects in memory. And the high-level dialect locks-in pointer-heavy GC object model! Even if you write your code in assembly, the performance ceiling will be determined by all those pointers GC needs. To actually get full “low-level ” performance, you need to effectively “mirror ” the data across the dialects across a quasi-FFI boundary.
