The Rust I Wanted Had No Future
This is maybe not clear enough, and it might make the question of whether the project “really should have had a BDFL” a little sharper to know this: the Rust We Got is many, many miles away from The Rust I Wanted.
[…]
I wanted crates to allow inlining inside but present stable entrypoints to the outside. Swift wound up close to here, it’s a huge technical headache but failure to do so is also a big part of Rust’s terrible compile times and lack of a stable ABI. I resisted this at the time and have objected to the choice ever since. It’s likely necessary in today’s Rust given the next point though.
[…]
Another thing that’s great to have a compiler open-code is an integer type that overflows to an owned or refcounted bignum type: shipping enough stuff to let this happen efficiently in libraries is a huge pain (even if you get as far as stable inline assembly it won’t go as fast as doing it in the compiler) and .. Rust just decided not to. I wanted it to, but I lost. Integers overflow and either trap or wrap. Great. Maybe in another decade we can collectively decide this is also an important enough class of errors to catch?
[…]
Tail calls. I actually wanted them! I think they’re great. And I got argued into not having them because the project in general got argued into the position of “compete to win with C++ on performance” and so I wound up writing a sad post rejecting them which is one of the saddest things ever written on the subject.
[…]
The priorities I had while working on the language are broadly not the revealed priorities of the community that’s developed around the language in the years since, or even that were being-revealed in the years during. I would have traded performance and expressivity away for simplicity -- both end-user cognitive load and implementation simplicity in the compiler -- and by doing so I would have taken the language in a direction broadly opposed to where a lot of people wanted it to go.
