There's this dynamic in the industry in which a brash young project comes out swinging against some established technique and commits early to its opposite. Then, as the project matures, its authors begin to understand why the old ways were the way they were and slowly walk back their early stridency --- usually without admitting they're doing it.
Consider Linux. Time was, metaprogramming was BAD, C was all you needed, we didn't need dynamic CPU schedulers, we didn't need multiple LSMs, and we sure as hell didn't need ABI stability. Now we have forms of all of these things (for the last, see CO-RE), because as it turns out, they're actually good.
In Python, well, turns out multiprocessing isn't all you need, and a free-threaded Python has transitioned from impossible and unwanted to exciting and imminent.
In transfer encodings, "front end" people thought that JSON was all you needed. Schemas? Binary encodings? Versioning? References? All for those loser XML weenies. Well, who's the weenie now?
And in Rust? Well, let's see. Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way. I expect yeet_expr to go through eventually too. Others are trying to stabilize (i.e. ossify) the notionally unstable ABI, just like they did to poor C++, which is now stuck with runtime pessimization because somebody is too lazy to recompile a binary from 2010.
As surely as water will wet and fire will burn, the gods of Java with stupidity and complexity return.
> And in Rust? Well, let's see. Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way. I expect yeet_expr to go through eventually too. Others are trying to stabilize (i.e. ossify) the notionally unstable ABI, just like they did to poor C++, which is now stuck with runtime pessimization because somebody is too lazy to recompile a binary from 2010.
Not to make an argument either way on your general point, but these are really bad examples for Rust if you look at the specifics:
Monomorphization was never the only option. Trait objects and vtables predate the RFC process itself. Early Rust wanted more dynamic dispatch than it eventually wound up with.
All the various initiatives related to stable ABI are focused on opt-in mechanisms that work like `#[repr(C)]` and `extern "C"`.
The only way to interpret these as examples of "brash young project walks back its early stridency as it ages" is if you ignore the project's actual reasoning and design choices in favor of the popular lowest-common-denominator Reddit-comment-level understanding of those choices.
> Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way.
This actually gets the history backwards. Ancient Rust tried to do generics in a fully polymorphic way using intensional type analysis, like Swift does. We switched to monomorphization reluctantly because of the code bloat, complexity of implementation, and performance problems with intensional type analysis. "dyn Trait" was always intended to be an alternative that code could opt into for runtime polymorphism.
Consider Linux. Time was, metaprogramming was BAD, C was all you needed, we didn't need dynamic CPU schedulers, we didn't need multiple LSMs, and we sure as hell didn't need ABI stability. Now we have forms of all of these things (for the last, see CO-RE), because as it turns out, they're actually good.
In Python, well, turns out multiprocessing isn't all you need, and a free-threaded Python has transitioned from impossible and unwanted to exciting and imminent.
In transfer encodings, "front end" people thought that JSON was all you needed. Schemas? Binary encodings? Versioning? References? All for those loser XML weenies. Well, who's the weenie now?
And in Rust? Well, let's see. Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way. I expect yeet_expr to go through eventually too. Others are trying to stabilize (i.e. ossify) the notionally unstable ABI, just like they did to poor C++, which is now stuck with runtime pessimization because somebody is too lazy to recompile a binary from 2010.
As surely as water will wet and fire will burn, the gods of Java with stupidity and complexity return.