[Info-vax] Rust as a HS language, was: Re: Quiet?
Simon Clubley
clubley at remove_me.eisner.decus.org-Earth.UFP
Tue Apr 5 13:53:39 EDT 2022
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.
Simon.
--
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
More information about the Info-vax
mailing list