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

[Bill Gunshannon]

On 4/5/22 15:04, Dan Cross wrote:
> 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.

Maybe I'm just confused, but I don't see what time has to do with
anyone writing code relying on the results of UB.  I would expect
there would be no guarantee of repeated results on the same hardware
using the same compiler and then running the program twice.  Or am
I missing just what "UB" actually means here.

bill