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

[Dan Cross]

In article <t2g5jj$8kb$1 at dont-email.me>,
Dave Froble  <davef at tsoft-inc.com> wrote:
>On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>> That people have old code bases that they build with old compilers or
>> run with old interpreters is not Python specific. Lots of companies
>> are buried in technical debt.
>
>Not "lots", but everyone.
>
>So often I see programmer types quite ready to change things.  Those footing the 
>bill may not be so eager.  In fact they are not.  For the programmers, it is job 
>security, it is polishing their resume.  Not good for anyone but the 
>programmers, and then they are not good for their employers.
>
>Off with their heads I say ...

I strongly disagree.  Technology evolves; over time, we learn
about things that work well and we adopt those things, and we
also learn about what does NOT work well, and let those things
fall by the evolutionary wayside.  This is good.

But it also means that our software has to evolve.  We hit new
scaling limits, we learn about things that work well in new
hardware and software environments, and critically, we learn
about things that do not work well.

C is an interesting case in point.  Post the 1988 standard,
compiler writers started to realize that they could take
advantage of "undefined behavior" in the standard to make
aggressive optimizations that changed the program to be
faster, but clearly violated the intent of the programmer.
For example:

    int a, b;
    if (a * b < 0) {
        // Handle overflow case.
    } else {
        // Do something.
    }

Well, signed integer overflow is UB in C, so a compiler is free
to elide the conditional entirely, thus never handling overflow
(and yes, this has appeared in the wild;
https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf).

So your program that "works" today may not "work" tomorrow, even
though it conforms to a standard, because the standard gives
implementations substantial leeway to do things you did never
anticipated.

Standards are not a panacea of compatibility.

>> [context: Rust changes]
>> Obviously nothing.
>
>If the users had any input to such decisions, it would not happen.

Backwards compatibility for stable Rust is a big goal of the
language and the community.  One could simply read up on it; all
of the documentation is available online.

	- Dan C.