Rust's 2018 roadmap

A lot of companies have tried to make products that are both infinitely backwards compatible and always supported while still introducing breaking changes like this. It quickly becomes a giant internal mess of trying to figure out what the most common denominator of feature requirements to implement new things is. Developers will start making ergonomic decisions in their changes (well, it could support 2021, but I want a 2024 feature so I'm going to use it and peg this feature to 2024 minimum) and new changes need to be tested against every different language iteration.

This might seem like the best answer now, I just hope its not biting off more than anyone can chew in 2030. C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s and it took Herb Sutter and friends to bring C++ back from the dead with one unified single truth of C++ with concrete compiler flags and tons of caution before adopting anything new to make sure all participants were capable of fielding it quickly enough to avoid the ecosystem fragmentation of the past.

Rust is advantaged today with only one major implementation, but if mrustc or other alternative Rust compilers become popular mixing those with epochs / eras / editions can spell disaster for language portability.

Its not an impossible task, but it is definitely a huge one. And its not the kind of work hobbyists will ever be willing to put up with in the long term, and its the kind of work that requires extraordinary familiarity with the whole of rustc, its design process, the RFCs, LLVM, etc. Its its opposite kind of work to what you put on the easy issues list for new contributors.

It is the primary reason why most software staggers its releases and depreciated support. Why Microsoft dropped Windows XP at all despite its wide adoption. Because even with billions of dollars of cash on hand trying to keep multiple parallel interconnected but distinct code paths functioning while both securing and improving them in isolation or together is in the highest echelons of software complexity and difficulty.

IE6 had exactly that issue, the DOM was implemented using COM which has its own GC (refcounting) separate from the regular JS runtime.

If you created a cycle between DOM and JS by, let's say, adding an event handler to a DOM node — thankfully that's something you'd never do when developing web pages & applications — you'd start leaking memory which would survive across page reloads.

There was actually a bit of software called Drip, it was just a webview wrapper (technically an MFC app with a browser COM component), you'd launch it, open your page, click the "blow memory" button and it'd reload the page over and over again listing elements which had survived between reloads.

Still, I think it's short and simple enough that it could have been noted in the section, which I feel currently talks about editions a lot but doesn't say much about them.

> Heres just hoping that Mozilla is prepared

Rust is an open source project Mozilla contributes to heavily, it's not a Mozilla project. This is the Rust project's problem, not Mozilla's problem.

(For example, Mozilla employees, of which I am one, are a minority in governance these days. We're the largest single group of people by employer, but are at 50% representation on the core team and are something like between 10%-20% of the rest of the teams, which have just as much jurisdiction over Rust as the core team does.)

> It quickly becomes a giant internal mess

This is why, as noted elsewhere in the thread, editions can only tweak the frontend of the compiler. By the time you hit MIR, the main intermediate representation, all edition differences are gone. This is for both compilers and humans. As you rightfully say, if we allowed arbitrary changes, it could significantly increase technical debt. But it'd also be very hard for humans to understand as well. We won't be fundamentally changing what Rust is for these reasons.

LTS is an entirely different axis. LTS is about artifacts, editions are about the language.

I'd really like to see us start an LTS policy this year, but we'll see.