On 2022-04-03, plugh <jchimene@gmail.com> wrote:
>
> Perhaps this will stimulate a discussion
>
> https://highassurance.rs

There are 3 things that switch me off from considering Rust as a HA language.
These 3 things are more important than any specific advantages that Rust
might have over other programming languages.

1) The syntax. It's horrible and imposes a higher cognitive load than
it needs to when you are looking at something new or revisiting old code.
That means you are more likely to miss something or work a lot harder
than you need to in order to understand the code.

One of the official Ada RMs/Style Guides/etc had it right when it pointed
out that you write the code once but read it many times. The Rust people
have forgotten this.

2) No official ISO or similar language standard I can rely on 5/10/20 years
from now when I need to work on my safety or general production critical
code at that point.

Even though many of the Rust people appear not to understand this, the
lack of those guarantees is a _massive_ problem in the real world.

3) Unlike mainstream programming languages, the Rust community always
seems to be lurching from one social drama to the next.

That in itself is an instant switchoff because the community is one
major social crisis away from falling apart (at least until it's then
rebuilt and a new direction emerges).

You can't rely on a programming language when something like that is
a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
language standards groups for example.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/4/2022 8:28 AM, Simon Clubley wrote:
> On 2022-04-03, plugh <jchimene@gmail.com> wrote:
>> Perhaps this will stimulate a discussion
>>
>> https://highassurance.rs
>
> There are 3 things that switch me off from considering Rust as a HA language.
> These 3 things are more important than any specific advantages that Rust
> might have over other programming languages.
>
> 1) The syntax. It's horrible and imposes a higher cognitive load than
> it needs to when you are looking at something new or revisiting old code.
> That means you are more likely to miss something or work a lot harder
> than you need to in order to understand the code.
>
> One of the official Ada RMs/Style Guides/etc had it right when it pointed
> out that you write the code once but read it many times. The Rust people
> have forgotten this.

Rust does not look anything like C/C++ or Pascal/Modula-2/Ada.

But it looks somewhat similar to newer languages like Kotlin and Swift.

It seems reasonable to believe that it can be read.

> 2) No official ISO or similar language standard I can rely on 5/10/20 years
> from now when I need to work on my safety or general production critical
> code at that point.
>
> Even though many of the Rust people appear not to understand this, the
> lack of those guarantees is a _massive_ problem in the real world.

Not really. Lot of popular languages are not formally standardized.
Python and PHP are not standardized. C# is/was standardized but the
standard is 6 versions behind. It took 13 years before C++ got
standardized.

If there is a desire for ISO Rust then it could happen. The likelihood
of it happening will increase if different implementations show up.

> 3) Unlike mainstream programming languages, the Rust community always
> seems to be lurching from one social drama to the next.
>
> That in itself is an instant switchoff because the community is one
> major social crisis away from falling apart (at least until it's then
> rebuilt and a new direction emerges).
>
> You can't rely on a programming language when something like that is
> a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
> language standards groups for example.

I don't think the number of heated discussions in the rust community
is unique. They may be a bit more transparent about it than most. And
the "internet tabloid press" loves that type of stuff. But has anything
actually been significant delayed due to it?

Arne

In article <t2eo9n$mj7$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-03, plugh <jchimene@gmail.com> wrote:
>>
>> Perhaps this will stimulate a discussion
>>
>> https://highassurance.rs
>
>There are 3 things that switch me off from considering Rust as a HA language.
>These 3 things are more important than any specific advantages that Rust
>might have over other programming languages.

Let's take a look.

>1) The syntax. It's horrible and imposes a higher cognitive load than
>it needs to when you are looking at something new or revisiting old code.
>That means you are more likely to miss something or work a lot harder
>than you need to in order to understand the code.
>
>One of the official Ada RMs/Style Guides/etc had it right when it pointed
>out that you write the code once but read it many times. The Rust people
>have forgotten this.

Surely this is subjective?

>2) No official ISO or similar language standard I can rely on 5/10/20 years
>from now when I need to work on my safety or general production critical
>code at that point.

This is a valid point.

>Even though many of the Rust people appear not to understand this, the
>lack of those guarantees is a _massive_ problem in the real world.

But this is just insulting to the Rust people. They aren't
fools. They understand the value of standards, but they're
still evolving the language. A standard will come in time.

>3) Unlike mainstream programming languages, the Rust community always
>seems to be lurching from one social drama to the next.
>
>That in itself is an instant switchoff because the community is one
>major social crisis away from falling apart (at least until it's then
>rebuilt and a new direction emerges).
>
>You can't rely on a programming language when something like that is
>a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
>language standards groups for example.

Oh really? It seems that the C++ community just went through a
bit of social "drama" with a convicted sex offender being
invited to a conference. Someone objected; that person was
shouted down. Chaos ensued.

In fact, I can't think of a language community that hasn't had
some kind of "drama" over the last 30 years or so that I've
been paying attention.

- Dan C.

On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/4/2022 8:28 AM, Simon Clubley wrote:
>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>> from now when I need to work on my safety or general production critical
>> code at that point.
>>
>> Even though many of the Rust people appear not to understand this, the
>> lack of those guarantees is a _massive_ problem in the real world.
>
> Not really. Lot of popular languages are not formally standardized.
> Python and PHP are not standardized. C# is/was standardized but the
> standard is 6 versions behind. It took 13 years before C++ got
> standardized.
>

You have just made my point for me Arne. Or to put it another way,
Python 2 to Python 3.

Why wasn't Python 3 just another language mode in the existing compiler
instead of being a whole different compiler ?

Why did Python 2.7 stay around for as long as it did ? How many are still
using it these days due to an existing code base ?

I can compile C89 code on a compiler 33 years later. When another standard
for C is released, it becomes just another language mode in the existing
compilers and all the existing C standards are still supported.

How confident are you that I can compile C89 code in yet another 10 years ?

In comparison, how confident are you that I can compile existing Python 3
or Rust code in another 10 years ?

What's to stop the Rust people from having some great language revamp a
few years from now and then stop supporting the existing language variant ?

The Python people did that and it's a _much_ more popular language than
Rust so what's to stop the Rust people from doing the same thing ?

> If there is a desire for ISO Rust then it could happen. The likelihood
> of it happening will increase if different implementations show up.
>
>> 3) Unlike mainstream programming languages, the Rust community always
>> seems to be lurching from one social drama to the next.
>>
>> That in itself is an instant switchoff because the community is one
>> major social crisis away from falling apart (at least until it's then
>> rebuilt and a new direction emerges).
>>
>> You can't rely on a programming language when something like that is
>> a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
>> language standards groups for example.
>
> I don't think the number of heated discussions in the rust community
> is unique. They may be a bit more transparent about it than most. And
> the "internet tabloid press" loves that type of stuff. But has anything
> actually been significant delayed due to it?
>

I'm talking about the social stuff, not the technical stuff.

It's the stuff that can become so toxic, it can cause a community
itself to become damaged.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t2eo9n$mj7$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>1) The syntax. It's horrible and imposes a higher cognitive load than
>>it needs to when you are looking at something new or revisiting old code.
>>That means you are more likely to miss something or work a lot harder
>>than you need to in order to understand the code.
>>
>>One of the official Ada RMs/Style Guides/etc had it right when it pointed
>>out that you write the code once but read it many times. The Rust people
>>have forgotten this.
>
> Surely this is subjective?
>

All I can say is that I've learnt lots of languages over the years and
the Rust syntax is easily the most ugly I have encountered.

>>2) No official ISO or similar language standard I can rely on 5/10/20 years
>>from now when I need to work on my safety or general production critical
>>code at that point.
>
> This is a valid point.
>
>>Even though many of the Rust people appear not to understand this, the
>>lack of those guarantees is a _massive_ problem in the real world.
>
> But this is just insulting to the Rust people. They aren't
> fools. They understand the value of standards, but they're
> still evolving the language. A standard will come in time.
>

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 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/4/2022 1:56 PM, Simon Clubley wrote:
> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/4/2022 8:28 AM, Simon Clubley wrote:
>>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>>> from now when I need to work on my safety or general production critical
>>> code at that point.
>>>
>>> Even though many of the Rust people appear not to understand this, the
>>> lack of those guarantees is a _massive_ problem in the real world.
>>
>> Not really. Lot of popular languages are not formally standardized.
>> Python and PHP are not standardized. C# is/was standardized but the
>> standard is 6 versions behind. It took 13 years before C++ got
>> standardized.
>
> You have just made my point for me Arne. Or to put it another way,
> Python 2 to Python 3.
>
> Why wasn't Python 3 just another language mode in the existing compiler
> instead of being a whole different compiler ?

(ignoring that I would not call Python a compiler)

The language has evolved. Most languages does.

They could have chosen to prioritize backwards compatibility higher.
Let us call it "Java approach".

They could have introduced a compatibility mode. Let us call it
"DEC C approach".

But they did not.

Would difference decisions have been made if it had been an ISO
committee and not a BDFL?

I don't know.

If the same people were making the decision then they may likely have
made the same decision. Whether they have a "core team" hat or an
"ISO WG member" hat should not change their opinion.

> Why did Python 2.7 stay around for as long as it did ? How many are still
> using it these days due to an existing code base ?

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.

> I can compile C89 code on a compiler 33 years later. When another standard
> for C is released, it becomes just another language mode in the existing
> compilers and all the existing C standards are still supported.

That is a choice. They can change it if they want to.

> How confident are you that I can compile C89 code in yet another 10 years ?

Compatibility seems to be a priority so that seems extremely likely.

> In comparison, how confident are you that I can compile existing Python 3
> or Rust code in another 10 years ?

Python - pretty sure. I believe the Python community learned the
lesson. Nobody expects an incompatible Python 4.

Rust - no idea. I don't follow the Rust community enough to know.

> What's to stop the Rust people from having some great language revamp a
> few years from now and then stop supporting the existing language variant ?

Obviously nothing.

Same applies to all languages.

You will have to evaluate. Do they claim they want to stay compatible?
Do you have faith in them do as they say? What is the community opinion?

I don't even know what the Rust people say about this.

But if they don't prioritize compatibility and you do, then it is
of course a reason to not pick rust.

>>> 3) Unlike mainstream programming languages, the Rust community always
>>> seems to be lurching from one social drama to the next.
>>>
>>> That in itself is an instant switchoff because the community is one
>>> major social crisis away from falling apart (at least until it's then
>>> rebuilt and a new direction emerges).
>>>
>>> You can't rely on a programming language when something like that is
>>> a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
>>> language standards groups for example.
>>
>> I don't think the number of heated discussions in the rust community
>> is unique. They may be a bit more transparent about it than most. And
>> the "internet tabloid press" loves that type of stuff. But has anything
>> actually been significant delayed due to it?
>>
>
> I'm talking about the social stuff, not the technical stuff.
>
> It's the stuff that can become so toxic, it can cause a community
> itself to become damaged.

Yes. Big headlines in the internet tabloids. No impact.

Arne

On 4/4/2022 2:07 PM, Simon Clubley wrote:
> On 2022-04-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2eo9n$mj7$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> 1) The syntax. It's horrible and imposes a higher cognitive load than
>>> it needs to when you are looking at something new or revisiting old code.
>>> That means you are more likely to miss something or work a lot harder
>>> than you need to in order to understand the code.
>>>
>>> One of the official Ada RMs/Style Guides/etc had it right when it pointed
>>> out that you write the code once but read it many times. The Rust people
>>> have forgotten this.
>>
>> Surely this is subjective?
>
> All I can say is that I've learnt lots of languages over the years and
> the Rust syntax is easily the most ugly I have encountered.

Ugly is practically by definition subjective.

>>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>> >from now when I need to work on my safety or general production critical
>>> code at that point.
>>
>> This is a valid point.
>>
>>> Even though many of the Rust people appear not to understand this, the
>>> lack of those guarantees is a _massive_ problem in the real world.
>>
>> But this is just insulting to the Rust people. They aren't
>> fools. They understand the value of standards, but they're
>> still evolving the language. A standard will come in time.
>
> 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.

There are no such guarantee.

There are plenty of examples of breaking changes.

Because even when prioritizing compatibility it is easy to make
something not compile - or worse compile with a different semantics.

18 years ago Java added an enum keyword. There were a surprisingly
amount of code using enum as a variable name.

> 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 ?

Rust is almost certainly going through a formal process. All
major languages has to.

Whether that process prioritize compatibility or not is up
the people involved in that process.

Arne

An example of very breaking language change: Scala 2 to 3.

Example code:

object Ooops {
def main(args: Array[String]): Unit = {
println("start")
val b = false
if(b) {
println("1")
println("2")
}
if(b)
println("3")
println("4")
println("finish")
}
}

It compiles/runs fine with both Scala 2 and 3.

But it does not print the same output.

:-(

Arne

On 4/4/22 12:56 PM, Simon Clubley wrote:

> Why wasn't Python 3 just another language mode in the existing compiler
> instead of being a whole different compiler ?

In a scripting language, that would have made for an extraordinarily
complicated and unmaintainable (and likely poor-performing) run-time
given that they were changing the fundamentals of how strings are stored
in a language where strings are a first-order data type.

In article <t2fc4n$fml$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2eo9n$mj7$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>1) The syntax. It's horrible and imposes a higher cognitive load than
>>>it needs to when you are looking at something new or revisiting old code.
>>>That means you are more likely to miss something or work a lot harder
>>>than you need to in order to understand the code.
>>>
>>>One of the official Ada RMs/Style Guides/etc had it right when it pointed
>>>out that you write the code once but read it many times. The Rust people
>>>have forgotten this.
>>
>> Surely this is subjective?
>
>All I can say is that I've learnt lots of languages over the years and
>the Rust syntax is easily the most ugly I have encountered.

Again, that's subjective. I can think of half a dozen languages
that I personally feel are much uglier than Rust, Ada and COBOL
among them. So what? My personal aesthetics have little
bearing on the matter.

Though in fairness, when I first saw Rust I thought to myself,
"big ugly language, but super small runtime and works on bare
metal." I have to admit, it's grown on me since then.

>>>2) No official ISO or similar language standard I can rely on 5/10/20 years
>>>from now when I need to work on my safety or general production critical
>>>code at that point.
>>
>> This is a valid point.
>>
>>>Even though many of the Rust people appear not to understand this, the
>>>lack of those guarantees is a _massive_ problem in the real world.
>>
>> But this is just insulting to the Rust people. They aren't
>> fools. They understand the value of standards, but they're
>> still evolving the language. A standard will come in time.
>
>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 ?

Again, they're not fools. They understand the value of a robust
standard; when the time comes, I have every confidence that one
will be produced under the auspices of a relevant standards body
but, again, that time hasn't come yet.

Languages usually have a bit of history behind them before they
get standardized.

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.

- Dan C.

On 4/4/2022 8:35 PM, Dan Cross wrote:
> In article <t2fc4n$fml$3@dont-email.me>,
> Simon Clubley <clubley@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.

Arne

On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/4/2022 8:28 AM, Simon Clubley wrote:
>>>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>>>> from now when I need to work on my safety or general production critical
>>>> code at that point.
>>>>
>>>> Even though many of the Rust people appear not to understand this, the
>>>> lack of those guarantees is a _massive_ problem in the real world.
>>>
>>> Not really. Lot of popular languages are not formally standardized.
>>> Python and PHP are not standardized. C# is/was standardized but the
>>> standard is 6 versions behind. It took 13 years before C++ got
>>> standardized.
>>
>> You have just made my point for me Arne. Or to put it another way,
>> Python 2 to Python 3.
>>
>> Why wasn't Python 3 just another language mode in the existing compiler
>> instead of being a whole different compiler ?
>
> (ignoring that I would not call Python a compiler)
>
> The language has evolved. Most languages does.

There is "evolve", and there is "replace" ...

> They could have chosen to prioritize backwards compatibility higher.
> Let us call it "Java approach".

Or, the VMS approach.

> They could have introduced a compatibility mode. Let us call it
> "DEC C approach".
>
> But they did not.
>
> Would difference decisions have been made if it had been an ISO
> committee and not a BDFL?
>
> I don't know.

I'm pretty sure that a committee of people already using the product would not
allow a break such Python 2 to Python 3. That is the difference, and it is a
major difference.

Much as it pains me, I have to state that Simon is "right on" with this discussion.

> If the same people were making the decision then they may likely have
> made the same decision. Whether they have a "core team" hat or an
> "ISO WG member" hat should not change their opinion.

Oh, but it does. When the developers are determined to do as they please, and
are not encumbered by users who might be affected, then you have the Python
issue. It can happen anywhere when there is not user input to decisions.

>> Why did Python 2.7 stay around for as long as it did ? How many are still
>> using it these days due to an existing code base ?
>
> 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 can compile C89 code on a compiler 33 years later. When another standard
>> for C is released, it becomes just another language mode in the existing
>> compilers and all the existing C standards are still supported.
>
> That is a choice. They can change it if they want to.
>
>> How confident are you that I can compile C89 code in yet another 10 years ?
>
> Compatibility seems to be a priority so that seems extremely likely.
>
>> In comparison, how confident are you that I can compile existing Python 3
>> or Rust code in another 10 years ?
>
> Python - pretty sure. I believe the Python community learned the
> lesson. Nobody expects an incompatible Python 4.

"Faith". Something not dependent on reality or facts.

> Rust - no idea. I don't follow the Rust community enough to know.
>
>> What's to stop the Rust people from having some great language revamp a
>> few years from now and then stop supporting the existing language variant ?
>
> Obviously nothing.

If the users had any input to such decisions, it would not happen.

> Same applies to all languages.
>
> You will have to evaluate. Do they claim they want to stay compatible?
> Do you have faith in them do as they say? What is the community opinion?
>
> I don't even know what the Rust people say about this.
>
> But if they don't prioritize compatibility and you do, then it is
> of course a reason to not pick rust.

And many other boondoggles ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/4/2022 2:46 PM, Arne Vajhøj wrote:
> On 4/4/2022 2:07 PM, Simon Clubley wrote:
>> On 2022-04-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <t2eo9n$mj7$1@dont-email.me>,
>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>> 1) The syntax. It's horrible and imposes a higher cognitive load than
>>>> it needs to when you are looking at something new or revisiting old code.
>>>> That means you are more likely to miss something or work a lot harder
>>>> than you need to in order to understand the code.
>>>>
>>>> One of the official Ada RMs/Style Guides/etc had it right when it pointed
>>>> out that you write the code once but read it many times. The Rust people
>>>> have forgotten this.
>>>
>>> Surely this is subjective?
>>
>> All I can say is that I've learnt lots of languages over the years and
>> the Rust syntax is easily the most ugly I have encountered.
>
> Ugly is practically by definition subjective.
>
>>>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>>> >from now when I need to work on my safety or general production critical
>>>> code at that point.
>>>
>>> This is a valid point.
>>>
>>>> Even though many of the Rust people appear not to understand this, the
>>>> lack of those guarantees is a _massive_ problem in the real world.
>>>
>>> But this is just insulting to the Rust people. They aren't
>>> fools. They understand the value of standards, but they're
>>> still evolving the language. A standard will come in time.
>>
>> 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.
>
> There are no such guarantee.
>
> There are plenty of examples of breaking changes.

There is also things such as Basic+, BP2, VAX Basic, DEC BASIC, Compaq BASIC, HP
BASIC, VSI BASIC that is probably 100% compatible. We have code originally
implemented back in the 1970s, which will still compile and run, correctly,
today. I will admit that the application has changed over the years, and
finding some of that old code might be a task, but, it will still do what it was
written to do.

Can anything be more valuable than that?

Is that something to desire?

> Because even when prioritizing compatibility it is easy to make
> something not compile - or worse compile with a different semantics.
>
> 18 years ago Java added an enum keyword. There were a surprisingly
> amount of code using enum as a variable name.
>
>> 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 ?
>
> Rust is almost certainly going through a formal process. All
> major languages has to.
>
> Whether that process prioritize compatibility or not is up
> the people involved in that process.

Not the users, huh?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/4/2022 9:29 PM, Dave Froble wrote:
> On 4/4/2022 2:46 PM, Arne Vajhøj wrote:
>> On 4/4/2022 2:07 PM, Simon Clubley 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.
>>
>> There are no such guarantee.
>>
>> There are plenty of examples of breaking changes.
>
> There is also things such as Basic+, BP2, VAX Basic, DEC BASIC, Compaq
> BASIC, HP BASIC, VSI BASIC that is probably 100% compatible.  We have
> code originally implemented back in the 1970s, which will still compile
> and run, correctly, today.  I will admit that the application has
> changed over the years, and finding some of that old code might be a
> task, but, it will still do what it was written to do.

Many languages prioritize compatibility.

> Can anything be more valuable than that?
>
> Is that something to desire?

It is a very desirable thing.

Code should be enhanced and improved, but preferably to meet
increase business demand not to keep up with an ever changing
language standard.

>> Because even when prioritizing compatibility it is easy to make
>> something not compile - or worse compile with a different semantics.
>>
>> 18 years ago Java added an enum keyword. There were a surprisingly
>> amount of code using enum as a variable name.
>>
>>> 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 ?
>>
>> Rust is almost certainly going through a formal process. All
>> major languages has to.
>>
>> Whether that process prioritize compatibility or not is up
>> the people involved in that process.
>
> Not the users, huh?

They make the decisions. They may or may not be influenced by
the end users.

Arne

On 4/4/2022 9:21 PM, Dave Froble wrote:
> On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/4/2022 8:28 AM, Simon Clubley wrote:
>>>>> 2) No official ISO or similar language standard I can rely on
>>>>> 5/10/20 years
>>>>> from now when I need to work on my safety or general production
>>>>> critical
>>>>> code at that point.
>>>>>
>>>>> Even though many of the Rust people appear not to understand this, the
>>>>> lack of those guarantees is a _massive_ problem in the real world.
>>>>
>>>> Not really. Lot of popular languages are not formally standardized.
>>>> Python and PHP are not standardized. C# is/was standardized but the
>>>> standard is 6 versions behind. It took 13 years before C++ got
>>>> standardized.
>>>
>>> You have just made my point for me Arne. Or to put it another way,
>>> Python 2 to Python 3.
>>>
>>> Why wasn't Python 3 just another language mode in the existing compiler
>>> instead of being a whole different compiler ?
>>
>> (ignoring that I would not call Python a compiler)
>>
>> The language has evolved. Most languages does.
>
> There is "evolve", and there is "replace" ...

We are talking evolve here. Replace is different.

>> They could have chosen to prioritize backwards compatibility higher.
>> Let us call it "Java approach".
>
> Or, the VMS approach.

Or the VMS Basic approach (to keep it around languages).

>> They could have introduced a compatibility mode. Let us call it
>> "DEC C approach".
>>
>> But they did not.
>>
>> Would difference decisions have been made if it had been an ISO
>> committee and not a BDFL?
>>
>> I don't know.
>
> I'm pretty sure that a committee of people already using the product
> would not allow a break such Python 2 to Python 3.  That is the
> difference, and it is a major difference.

>> If the same people were making the decision then they may likely have
>> made the same decision. Whether they have a "core team" hat or an
>> "ISO WG member" hat should not change their opinion.
>
> Oh, but it does.  When the developers are determined to do as they
> please, and are not encumbered by users who might be affected, then you
> have the Python issue.  It can happen anywhere when there is not user
> input to decisions.

I do not believe that "ISO WG = end user influence" and "Core team = no
end user influence".

>>> I can compile C89 code on a compiler 33 years later. When another
>>> standard
>>> for C is released, it becomes just another language mode in the existing
>>> compilers and all the existing C standards are still supported.
>>
>> That is a choice. They can change it if they want to.
>>
>>> How confident are you that I can compile C89 code in yet another 10
>>> years ?
>>
>> Compatibility seems to be a priority so that seems extremely likely.
>>
>>> In comparison, how confident are you that I can compile existing
>>> Python 3
>>> or Rust code in another 10 years ?
>>
>> Python - pretty sure. I believe the Python community learned the
>> lesson. Nobody expects an incompatible Python 4.
>
> "Faith".  Something not dependent on reality or facts.

The fact is that any language can decide to make a breaking
change.

The only difference is how likely one consider it.

Arne

On 4/4/2022 10:18 PM, Arne Vajhøj wrote:
> On 4/4/2022 9:29 PM, Dave Froble wrote:
>> On 4/4/2022 2:46 PM, Arne Vajhøj wrote:
>>> On 4/4/2022 2:07 PM, Simon Clubley 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.
>>>
>>> There are no such guarantee.
>>>
>>> There are plenty of examples of breaking changes.
>>
>> There is also things such as Basic+, BP2, VAX Basic, DEC BASIC, Compaq BASIC,
>> HP BASIC, VSI BASIC that is probably 100% compatible. We have code originally
>> implemented back in the 1970s, which will still compile and run, correctly,
>> today. I will admit that the application has changed over the years, and
>> finding some of that old code might be a task, but, it will still do what it
>> was written to do.
>
> Many languages prioritize compatibility.
>
>> Can anything be more valuable than that?
>>
>> Is that something to desire?
>
> It is a very desirable thing.
>
> Code should be enhanced and improved, but preferably to meet
> increase business demand not to keep up with an ever changing
> language standard.

Yes, this is the key.

Some time ago, perhaps in the 1990s, not sure, the Basic developers took a look
at things in general, and declared "we can implement just about anything".
Basic got the RECORD statement, basically similar to structures in C, and some
other things. The concept was "add helpful things, but don't break anything".
That was rather useful.

Another example, I can use Visual Basic a bit. I cannot use VB .NET. Not sure
of all the differences, but a VB program will not compile in .NET. That was
rather distasteful.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <t2g5jj$8kb$1@dont-email.me>,
Dave Froble <davef@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.

In article <624b909b$0$703$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/4/2022 8:35 PM, Dan Cross wrote:
>> In article <t2fc4n$fml$3@dont-email.me>,
>> Simon Clubley <clubley@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.

Yup. That's it. They give pretty strict guarantees of
backwards compate for the stable parts of the language.
They saw the messes in Python on other languages, and
consciously sought to avoid them.

- Dan C.

So, I have been following this discussion for some time now. I have
never used Rust. I have never even looked at Rust. But I do have one
question.

Just what is it that Rust can do that none of the already existing
languages could do?

bill

"Chaos, Confusion, Disorder.... My work here is done." :)

To most of you who didn't really follow the original link, please favour my posting some interesting (to me) bits:

"The prior chapter walked through a Rust library and CLI tool in the service of introducing software security concepts. This chapter will focus on the Rust language proper - we'll tour its syntax, features, and conventions.
Now we won't be covering all of Rust. It's a big language. Much closer to C++ than C. Our favorite comprehensive Rust book, Programming Rust, is a 700+ page tome, a relentless enumeration of language features. Now it's a phenomenal book, and a major inspiration for this one. But we're talking multiple-Costco-mini-barrels-of-whole-bean-coffee kinds of endurance.
Part of the challenge is the sheer breadth of features Rust offers. Being a relatively new language, Rust has the benefit of hindsight: it's free to cherry-pick successful aspects of its predecessors.
This includes OCaml's algebraic data types, C++'s monomorphization, Scheme's hygienic macros, etc2. While the Rust Team strives for a cohesive design3, the language juggles several influences.
Fortunately for us, you don't need an exhaustive understanding of Rust to be productive in it. This section previews key concepts - just enough to get you started reading and writing Rust snippets. We'll cement those concepts in the rest of the book by building an embedded-friendly, high assurance library.
With that as a foundation, you'll be prepared to write your own real-world Rust programs. And to tackle learning additional language features (smart pointers, channels, async, macros, etc) as project needs arise.
Our tour of Rust will be broken into six short-ish parts:
Low-Level Data Representation - primitives, tuples, arrays, references, and slices.
High-level Data Representation - structs, enums, generics, and traits.
Control Flow - conditional statements, loops, and pattern matching.
Ownership Principles - understanding the core principles of Rust's most novel feature.
Ownership in Practice - concepts for working with ownership day-to-day.
Error Handling - propagating failures and/or maintaining availability."

-- https://highassurance.rs/chp3/_index.html

The reason for posting this topic on comp.os.vms is that this language allows one to write software that provably eliminates (!) certain classes of Undefined Behavior. I can't stress the importance of that to those of us whose still writing C

I posit that those interested in the intersection of such languages and VMS will find this a useful language, and worth their time to study. Even if it's not available on VMS

On Tuesday, April 5, 2022 at 6:04:27 AM UTC-7, Bill Gunshannon wrote:
> So, I have been following this discussion for some time now. I have
> never used Rust. I have never even looked at Rust. But I do have one
> question.
>
> Just what is it that Rust can do that none of the already existing
> languages could do?
>
> bill

For this particular topic, it eliminates certain classes of Undefined Behavior. There's a great deal more, but I'd start there.

To follow up on the UB focus:

"Undefined behavior is still possible in Rust, if using unsafe keyword6, but it's almost eliminated in the safe subset of Rust. That's a major part of why the Rust language is so amenable to writing correct, reliable software.. Rust removes UB, nearly entirely, by default.
Why the "almost eliminated" and "nearly entirely" caveats?
At the time of this writing, Rust does not yet have an official language standard or specification, like C or C++. So it's difficult to make a definitive claim.
The Rust Reference contains a non-exhaustive list of behaviors considered undefined in Rust6, all of which would require the unsafe keyword to introduce. So there are likely only two potential sources of UB in Rust:
unsafe blocks whose invariants aren't actually upheld (our fault).
Rare compiler bugs7 that threaten soundness (patched once discovered)."
-- https://highassurance.rs/chp3/undef.html

On Tuesday, April 5, 2022 at 6:17:25 AM UTC-7, plugh wrote:
> On Tuesday, April 5, 2022 at 6:04:27 AM UTC-7, Bill Gunshannon wrote:
> > So, I have been following this discussion for some time now. I have
> > never used Rust. I have never even looked at Rust. But I do have one
> > question.
> >
> > Just what is it that Rust can do that none of the already existing
> > languages could do?

It also teaches what shit code one has written over their professional career.

In article <jb2t2oF49voU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>So, I have been following this discussion for some time now. I have
>never used Rust. I have never even looked at Rust. But I do have one
>question.
>
>Just what is it that Rust can do that none of the already existing
>languages could do?

There are three main interacting features that are unique in
their combination in the language that Rust brings to bear:

1) Lifetimes attached to pointers are a first-class primitive in
the language. They are literally part of the type.
References cannot outlive the objects they refer to.
2) A compile-time borrow checker that ensures that either a
single mutable reference to an object, or one or more
immutable references. In safe rust code, data races are
impossible.
3) Object ownership is a first-class primitive in the language,
and every object has exactly one owner. All objects must be
initialized before use. Dangling pointers and uninitialized
pointers are

The combination of these things is incredibly powerful, and
gives you type and memory safety _without garbage collection_.
The result is that you program as if you were using a managed
language, but with explicit control over memory allocation.

You can even do this on bare metal. The langauge gives you a
high degree of abstraction with the "core" library, even in
kernel mode. In that context, it's actually quite pleasant to
use.

- Dan C.

On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>
>> Why wasn't Python 3 just another language mode in the existing compiler
>> instead of being a whole different compiler ?
>
> (ignoring that I would not call Python a compiler)
>

In that case, would you have said (for example) UCSD Pascal wasn't
a compiler ?

Python can output .pyc files but also has a way of running code
interactively if desired.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.