[Info-vax] Rust as a HS language, was: Re: Quiet?

[Dan Cross]

In article <t2hvn3$lpu$4 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-04, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 4/4/2022 8:35 PM, Dan Cross wrote:
>>> In article <t2fc4n$fml$3 at dont-email.me>,
>>> Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>> But other languages are also evolving over time, and they do it in
>>>> a way that guarantees the next language variant is just another
>>>> language mode in the existing compilers. That means I know I can still
>>>> compile code written to that old language variant in the years to come.
>>>>
>>>> If the Rust language isn't going through a formal language standards
>>>> process, how do I know that I can compile existing Rust code in
>>>> 5/10/20 years time ?
>>
>>> As for the, "how can I be sure my code will compile..." question
>>> have a look at Rust "editions", that are per-crate attributes.
>>> They provide exactly the sort of guarantees you are looking for.
>>
>> This thing:
>>
>> https://doc.rust-lang.org/edition-guide/editions/index.html
>>
>> ?
>>
>> It actually looks like Rust do prioritize compatibility.
>>
>
>Interesting. But it looks like there are limits with that approach:
>
>|The requirement for crate interoperability implies some limits on the kinds
>|of changes that we can make in an edition. In general, changes that occur
>|in an edition tend to be "skin deep". All Rust code, regardless of edition,
>|is ultimately compiled to the same internal representation within the
>|compiler.
>
>That looks like it wouldn't work so well if Rust decided to make major
>internal functionality changes that couldn't compile to the same internal
>representation.

Which is probably a pretty decent indication that they don't
intend to do that.  You may find it instructive to read up on
the guarantees they make about "stable" language features; they
are actually quite conservative about what they stabilize.

A committee driven standards document (which, to reiterate yet
again, _will_ come) isn't a talisman against incompatibility.
Again, I bring up how pervasive use of UB in C means that
programs written 30 years ago to the then-current standard will
fail today when compiled with modern toolchains.

	- Dan C.