Its almost like fixing compiler bugs means no language is truly ever backwards compatible for long...
The question then is how does someone define backward compatibility?
The answer is a formal definition of what the expected behaviors and expectations of the programming language in question. This usually means a language specification or extensive unit tests that effectively define what the programming language should or should not do for a given set of circumstances.
As someone who's invested a lot of time in PLT and even at one point had their name on a draft of the Haskell standard, the unfortunate reality is that language specifications are very often not useful to the wide majority of people, while being quite laborious to produce and maintain and work with over time. The culture of computer programming, at large, is part of this, it's not some mathematical fact, but a social one. At the end of the day, what constitutes "Rust the language" in any formal capacity doesn't matter; "Rust the language" is a social construct in that sense, a guarantee Rust will still be Rust even if some minor bugs are fixed that they let slip by. This is how most people think of it, when you get down to the nitty gritty.
I'll also say that tons of regressions happen in mature languages with backwards compatibility. Ask any Linux distro maintainer! I don't even keep track of all the weird reasons regressions happen anymore; it's like counting sand on a beach. It's not a happy fact of life, but it is what it is, and regressions do happen, no matter if your language is stable for 5 years or 50.
What you are describing is the less fun and sometimes tedious nature of software maintenance.
It can be thankless work, but it is very important work to ensure that a programming language is reliable and to minimize the regressions that sometimes occur.
It is very much a social contract, but essential so that expectations are met, particularly for systems programming that Rust targets.
I wonder if anyone has ever tried to create a literate programming-style specification for programming languages--something that combines the high-level descriptions of programming language semantics with executable unit tests. Such a system would provide detailed semantics and give programming language creators and maintainers a good way to prevent regressions and create RFC branches to try out and test new ideas. It would help to bring the social constructs of the programming language closer to the technical implementation semantics.
The Ada programming language has a specification: http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TTL.htm...
and a conformity test suite: http://www.ada-auth.org/acats.html
which ensure that any Ada implementation conforms to what the specification requires.
Does anything similar exist for other programming languages? If so which languages have conformity tests or similar?
I use Ada professionally and Rust as a hobbyist. Rust is moving very fast and I would like to see it mature for use in safety critical domains.
Also, thank you for your work on Haskell.
Some quotes from the linked page:
> Ferrocene is a sustainable effort led by Critical Section GmbH, a newly formed Ferrous Systems subsidiary, tasked with making Rust a first-class language for mission and safety-critical systems. Ferrocene produces a qualified Rust compiler toolchain. General availability is expected by the end of 2022.
And also:
> Ferrocene is a vehicle for a versioned Rust and MIR specification, paired with automated verification of Rust semantics. These "runnable specs" give developers in mission-critical and high-security environments a sound, proven, and addressable foundation for building critical libraries, analysis tools, and further system assurances.
And also:
> Critical Section will maintain designated legacy versions of the Rust toolchain and supporting utilities. This support includes backporting fixes of critical language and standard library issues (performance bugs, unsoundness, security) and maintaining key rustc targets, including test cases and platform-specific testing.
And finally:
> Ferrocene is a principled project with much work ahead, requiring cross-industry collaboration and continuous feedback. It has support from crucial industry partners and subject experts, and we're building a thoughtful community.
> Right now, Ferrous Systems and Critical Section are calling for additional partners to join this effort. We're currently looking for partners from diverse industries
It is informative for example to review talks Bjarne gave about C++ Concepts in 2015 compared to the C++ 20 feature Concepts. That's five years to get something similar in scope into the actual language standard, and of course since this isn't exactly what Bjarne designed, you then to have transition compilers and codebases to the actual standard feature...
I'm dubious about the value of conformance testing as a deliberate exercise. In practice real world implementations will definitely be defective and it's important that defects are cured when identified, mostly by changing implementations but sometimes in reality by changing the specification to reflect what is implemented. But I don't know how much value I believe there is in somebody sitting down to try to construct a test suite starting from the standards documents, rather than gathering minimal samples of real world code that did not do what the standard says it should do so that implementations can check they get those right (and where appropriate the standards body can reconsider whether the standard itself is wrong here). It appears to me that ACATS tries to do the former, right?