Defining the Rust 2024 edition

Posted Jan 30, 2024 11:44 UTC (Tue) by khim (subscriber, #9252)
In reply to: Defining the Rust 2024 edition by pizza
Parent article: Defining the Rust 2024 edition

> Now one can reasonably argue that this "requiring the complete corresponding source code to _everything_" consequence is actually a GoodThing(tm), but let's not pretend that the world solely consists of F/OSS.

There are absolutely no such pretence. Rust supports binary libraries just fine. It just makes the people who produce these to pay for the ABI stability and the ability to use shared library compiled with different versions of rust compiler.

It's the same deal lovers of tracing GC got: tracing GC is not outright banned by Rust, there are various crates and other things… but since that means tracing GC lovers pay actual price of having that abomination in your codebase… proposal, suddenly, becomes crazy unattractive to the majority of people.

I would say that when C++ ended up with frozen ABI and all these other things that follow from that it violated it's very basic principle: you don't pay for what you don't use. Everyone pays huge price for the ABI stability — even people who don't need it. That's wrong.

Now, it would probably be an interesting exercise to think about how one may introduce some kind of optional opt-in sublibrary which would exist somewhat “outside” of normal core/std yet still would be able to work with them (e.g. you need to be able to declare stable Result<usize, std::stable::Error> somehow).

But I'm very unsure about whether all that complexity is even needed. C/C++ (and also, probably, Java) are weird outliers as far as ABI stability is concerned. Most other languages don't do that and after looking on what happened in Java world when it needed to update one measly library because there was vulnerability found in it… I would rather keep all that work entirely separate from core language.

It's not that I'm against binary packages, far from it, I'm against makers of these binary packages dictating the rules. They want to ensure these would be usable in future versions of Rust, they have to pay for the development and support of that ability.

P.S. One interesting example which I don't know what to think about is Swift. Swift developers have consciously decided to pay a very hefty price for the ABI stability, because Apple needed it. It made Swift an obvious Apple-only language and that helps to mitigate the damage (Apple have the ability to make developers upgrade). Not sure if Rust may adopt that model and even less sure about whether it's worth adopting it.