Rustaceans at the border

That Usually is because of monumental sacrifices in implementation quality (I am a C++ standard library maintainer). A regex that is slower than spinning up a java vm, doing the regex, and then shutting it down. A hash table that is 2x slower than it should be. An insane work stealing thread implementation that just exists to get around big kernel locks that were removed 20 years ago. A mutex that is huge and deadlocks under resource starvation. A buffered IO stream that buffers like 16 characters. A deque (linked list of buckets) with a bucket size optimized for caches from 1995. A span type that is always passed on the stack because we forgot to add the attribute to say we want the sane ABI, the one we cant make the default because that would break ABI. The only data structures that are pretty OK are the vector and the r-b tree. The lists are not horrible either, but “generic” linked lists are not terrifically useful things.

The ability to provide a stable ABI is great, but C++ has gotten into a position where the first “real” release of your library has a stable ABI and boy is that not a good thing.

Even with all the care that we take not to break abi we still break it accidentally in subtle ways from time-to-time, as do other implementations. The way C++ libraries are designed and the way the standard library in particular is specified are at complete odds with the ability to make any kind of future changes without breaking ABI. You can do such libraries, but they look like Qt, POCO, or a COM library rather than your typical boost/standard library.

Swift gets this very much right. I wish it integrated with a jit of some kind to allow slowly migrating to the “unstable abi” versions of stuff though (and switching back when the dependency changes)

Fun tidbit: I recall that for Windows Phone 7 apps were distributed as bytecode in the compiler’s intermediate format and compiled to a final executable on the phone during installation.