3 ms·
Never breaking compatibility is hardly a new idea. Java and C++ have invested tremendous amounts of effort into preserving backwards compatibility for decades,
by the_duke 3y ago
Never breaking compatibility is hardly a new idea.
Java and C++ have invested tremendous amounts of effort into preserving backwards compatibility for decades, often requiring bending over backwards and very suboptimal designs for new features, especially in C++.
But it keeps users happy. At least the ones with large old code bases.
I think Rust has one of the cleanest models for this, which keeps complexity low: editions.
The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability.
Of course Rust is still pretty young, and if this model will work long term remains to be seen. For example, I imagine this causes a lot of implementation complexity in the compiler, the standard library is much more restricted and must remain stable across editions, and major overhauls probably won't be possible.
But so far it has worked out really well, allowing the team to fix warts and mistakes in the language.
- deleted 3y ago[deleted]
- zigzag312 3y agoI would upvote this twice if I could. We will never break compatibility is code for "we will never fix warts and mistakes in the language".
- tptacek 3y agoIt obviously isn't, as the text of the article repeatedly observes.
- zigzag312 3y agoYou are right. I haven't read the article and just assumed. It's actually about how they enabled introducing "breaking" changes without actually breaking backwards compatibility with existing code. Which is best possible outcome.
- glenjamin 3y agoDid you read the article? > The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability. This is exactly what the GODEBUG scheme described in the article is intended to allow.
- the_duke 3y agoEdit: I had some wrong assumptions here. The Go approach does indeed seem to enable similar functionality. Although I'm not quite sure I understand how the individual settings and the module level version declarations compose, and how much complexity that introduces. With both module-level versions and GODEBUG, the whole thing does seem quite a bit more complicated than editions.
- vocx2tx 3y ago> The setting is opt-out, requiring manual intervention. No. If a module's go.mod files declares go1.21, the compiler will use go1.21 semantics when building it, even if 1.22 has already been published and the module is being used from a 1.22-enabled program. This is explicitly mentioned in the blog post.
- tick_tock_tick 3y agoIt's basically a much more featured, flexible, extendable, and usable version of editions. Anything you could do with editions you could do with this; you could implemented "editions" via this functionality.
- the_duke 3y agoYes, but that's sort of my point regarding complexity. "This crate is edition X, and an edition comes out every 3 years or so" is much easier to deal with. It reminds me a bit of Haskell language pragrams, which can be toggled per source file (module), and which are a huge mess.
- izacus 3y agoCan you explain in what way is that different from e.g. C++, where a compiler will take "-std=<C++ revision>" parameter which chooses the "edition" of the language? And even link different versions together? Because it sounds like Rust uses the same approach with the benefit of not hitting all the problems this causes... yet.
- kaba0 3y agoI would also be interested in it. As far as I know editions only allow for syntax changes, the semantics will change if incompatible, especially that Rust doesn't link across different versions in the same way as C++ does.
- uluyol 3y agoC++ unfortunately does textual inclusion for header files. So "-std=" does not automatically work for those. You need to sprinkle in #ifdefs rather than getting automatic forward compatibility.