On 2022-04-06, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <624d95fe$0$706$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>On 4/5/2022 2:05 PM, Simon Clubley wrote:
>>> It looks like Rust has come up with rather unique ways to screw up:
>>
>>I think you have a mysterious understanding of what is unique in
>>programming.
>>
>>(and this is not Rust as such but libraries written in Rust)
>
> Indeed. I read that quip as a statement along the lines of,
> "tell me you don't know Rust without telling me that you don't
> know Rust."
>

Actually, both of you have missed the point.

My point is that this all-new all-singing programming language that
will save us all (according to its creators) is released with all
these new and unique features that make Rust better than anything
else out there for security (also according to its creators).

People then start using this language to create libraries and manage
to still write code that compromises these new safety features, hence
making the library unsafe, but unsafe in a way that is unique to Rust
because it manages to violate the guarantees that the language says
it gives you.

And before you say it, I know Rust is not unique in this and that is
exactly the point. Just as you have to do when writing code in other
programming languages, you still have to know what you are doing when
writing Rust code or you can still write code that has security issues
within it.

And my attitude-free serious point is this: Rust brings some new ideas
to the table and they are ideas that are worth exploring. But at the
end of the day, it's just another tool with some more features built in
that can help you write more secure code and make it harder for you
to screw up.

Unfortunately, listening to people pushing the general Rust hype, they
would have you believe that Rust is some super-language that will instantly
solve all your security problems, even in code written by novices, if you
just start writing code in it and manage to get your code to compile.

That's not true and it's not true for any language that we have created.
It's just that there are some languages out there that make it a _lot_
harder to screw up in than in other languages and for which you can write
much safer (NOTE: much safer, _not_ safe) code more easily.

But you can still screw up even in those languages if you try hard enough
and if you don't really know what you are doing and that applies to all
languages we have ever created including both Ada and Rust.

Simon.

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

On 4/6/2022 2:18 PM, Simon Clubley wrote:
> My point is that this all-new all-singing programming language that
> will save us all (according to its creators) is released with all
> these new and unique features that make Rust better than anything
> else out there for security (also according to its creators).
>
> People then start using this language to create libraries and manage
> to still write code that compromises these new safety features, hence
> making the library unsafe, but unsafe in a way that is unique to Rust
> because it manages to violate the guarantees that the language says
> it gives you.

Total BS.

Rust provide exactly what it says it provides.

There are different levels of guarantees for normal Rust code
and Rust code marked unsafe.

As far as I know then Rust meet those guarantees.

If you know otherwise then file a bug report.

Rust could not be used for what it is used for without the unsafe
option.

Having a risk in 1% of the code (clearly marked as such) is way better
than having the risk in 100% of the code.

> And before you say it, I know Rust is not unique in this and that is
> exactly the point. Just as you have to do when writing code in other
> programming languages, you still have to know what you are doing when
> writing Rust code or you can still write code that has security issues
> within it.

Obviously. No language can prevent all programming errors.

> And my attitude-free serious point is this: Rust brings some new ideas
> to the table and they are ideas that are worth exploring. But at the
> end of the day, it's just another tool with some more features built in
> that can help you write more secure code and make it harder for you
> to screw up.

Yes. That is sort of the whole point in the evolution of programming
languages.

> Unfortunately, listening to people pushing the general Rust hype, they
> would have you believe that Rust is some super-language that will instantly
> solve all your security problems, even in code written by novices, if you
> just start writing code in it and manage to get your code to compile.

I don't think I have ever met someone like that.

Example?

> That's not true and it's not true for any language that we have created.
> It's just that there are some languages out there that make it a _lot_
> harder to screw up in than in other languages and for which you can write
> much safer (NOTE: much safer, _not_ safe) code more easily.
>
> But you can still screw up even in those languages if you try hard enough
> and if you don't really know what you are doing and that applies to all
> languages we have ever created including both Ada and Rust.

Yes.

Arne

In article <t2klgp$dm4$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-06, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <624d95fe$0$706$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>On 4/5/2022 2:05 PM, Simon Clubley wrote:
>>>> It looks like Rust has come up with rather unique ways to screw up:
>>>
>>>I think you have a mysterious understanding of what is unique in
>>>programming.
>>>
>>>(and this is not Rust as such but libraries written in Rust)
>>
>> Indeed. I read that quip as a statement along the lines of,
>> "tell me you don't know Rust without telling me that you don't
>> know Rust."
>
>Actually, both of you have missed the point.

I'm afraid your point is based on either confusion or lack of
familiarity.

>My point is that this all-new all-singing programming language that
>will save us all (according to its creators) is released with all
>these new and unique features that make Rust better than anything
>else out there for security (also according to its creators).

I invite you to provide a citation to one of the Rust creators
making such a claim.

Again, these people aren't fools: they understand that no one
language is the One True Solution to All Problems. The people
who designed and implemented Rust are actually qualified PL
people. You seemed to have glombed onto the fan boys pitching
hype and somehow think that's representative of the folks
actually doing the work: it is not.

>People then start using this language to create libraries and manage
>to still write code that compromises these new safety features, hence
>making the library unsafe, but unsafe in a way that is unique to Rust
>because it manages to violate the guarantees that the language says
>it gives you.
>
>And before you say it, I know Rust is not unique in this and that is
>exactly the point. Just as you have to do when writing code in other
>programming languages, you still have to know what you are doing when
>writing Rust code or you can still write code that has security issues
>within it.

No one serious ever claimed otherwise.

>And my attitude-free serious point is this: Rust brings some new ideas
>to the table and they are ideas that are worth exploring. But at the
>end of the day, it's just another tool with some more features built in
>that can help you write more secure code and make it harder for you
>to screw up.

Perhaps if you eliminated the hyperbole elsewhere and just lead
with this, you'd find that it gets a better reception.

>Unfortunately, listening to people pushing the general Rust hype, they
>would have you believe that Rust is some super-language that will instantly
>solve all your security problems, even in code written by novices, if you
>just start writing code in it and manage to get your code to compile.

No one serious has ever claimed that.

>That's not true and it's not true for any language that we have created.
>It's just that there are some languages out there that make it a _lot_
>harder to screw up in than in other languages and for which you can write
>much safer (NOTE: much safer, _not_ safe) code more easily.
>
>But you can still screw up even in those languages if you try hard enough
>and if you don't really know what you are doing and that applies to all
>languages we have ever created including both Ada and Rust.

Again, no one credible ever claimed otherwise.

- Dan C.

In article <jb5s77FlsqfU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/5/22 20:20, Arne Vajhøj wrote:
>> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
>>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>> C and C++ are currently dominating the low level code area, but
>>>> there are some well known problem.
>>>>
>>>> Two of those problems are:
>>>> * buffer overruns
>>>> * memory leaks
>>>
>>> Both those problems were fixed 40 years ago.  The fixes were
>>> ignored and the company offering Safe C went out of business.
>>
>> They were not fixed as the current C compilers allow
>> the problems.
>>
>> Maybe they could have been fixed, but that does not really
>> help those with C code today.
>
>Let me re-word that. 40 years ago the problems were well known
>and documented.

No. Entire new classes of problems have emerged in those 40
years, and you have and continue to ignore those. It's not
_just_ array bounds and memory leaks that are at issue.

- Dan C.

In article <624da157$0$701$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/6/2022 9:56 AM, Dan Cross wrote:
>> In article <624d911f$0$702$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/5/2022 9:30 PM, Dan Cross wrote:
>>>> Eh? It's commonly accepted that you're going to give up some
>>>> percentage of your capacity for GC overhead.
>>>
>>> No it is not.
>>
>> Sorry, but yes it is.
>>
>>> With generational garbage collectors it is very fast to GC
>>> short lived objects.
>>
>> That does not mean that you aren't going to give up some
>> percentage of your capacity for GC. GC is not infinitely fast.
>
>No.
>
>But it does not need to use zero CPU.
>
>It just need to be faster than the manual free calls.
>
>Which it is.

Ah, but then it's dependent on workload and allocation patterns.
You seem to be making a general claim to a problem that does not
have a single, generally accepted solution.

>>> Go GC use STW. They have managed to reduce the time but it is
>>> still a STW.
>>
>> Note that I said that, "Go's concurrent GC _mostly_ avoids
>> that unless under severe memory pressure."
>
>A GC STW is a GC STW.

I think you missed the point. I never claimed that the Go GC
doesn't stop the world. It just mostly avoids it.

>>> The only GC I am aware of that does not do STW is Azul Zing.
>>
>> The LVB in Azul is basically a localized pause. It may be true
>> that Azul doesn't STW, but that doesn't mean that it's free.
>
>Of course it is not free.
>
>It may likely use more CPU than a STW GC.

....and may even be slower than explicit allocation!

>But it avoid STW.
>
>(and it is Azul Zing - Azul Zulu is using traditional STW GC)

Which was the topic of the paper I cited.

>> Under severe memory pressure pretty much all of the threads will
>> block in the LVB and the situation will be more or less
>> indistiguishable from a STW pause.
>
>That is not what tests show.
>
>Tests show that Azul Zing avoid the GC pauses.

I think you mean _global_ GC pauses.

>Hazelcast did a test with traditional JVM and Azul JVM.
>
>Results showed that 99% percentile was 2 ms for both,
>but 99.99% percentile was 40 ms for traditional and 8 ms
>for Azul Zing.
>
>It works.

Did you read the paper I cited?

- Dan C.

On 04/06/22 01:27, Dan Cross wrote:
> In article<624cdd77$0$704$14726298@news.sunsite.dk>,
> Arne Vajhøj<arne@vajhoej.dk> wrote:
>> On 4/5/2022 8:21 PM, Dan Cross wrote:
>>> In article<t2ilf1$18mj$1@gioia.aioe.org>,
>>> chris<chris-nospam@tridac.net> wrote:
>>>> I think the point is that languages take time to evolve and the path
>>>> can be unstable until there is enough critical mass to produce a fully
>>>> documented and standard version. I would expect that to take a decade
>>>> or more. No good for serious work without that professionalism. Toy
>>>> and experimental otherwise.
>>>
>>> Java doesn't have a "standard" in the sense described here, but
>>> much as I don't care for it as a language I'd be hard pressed to
>>> describe it as a "toy" or "no good for serious work."
>>
>> Java is not ISO/ANSI/ECMA standardized.
>>
>> But the JCP process is really very similar to ISO/ANSI/ECMA.
>
> Sounds kind of like the Rust RFC process, but some posters here
> seem to have suggested that without a document produced under
> the auspicies of a relevant standards body, a language is not
> viable for serious work.
>
> - Dan C.
>

I wasn't suggesting that, but it takes years for all the issues
to be resolved and a language to become mature. That and the
language tends to be more fully documented formally. Sure, there
are always issues, but C has been around for long enough now that
most skilled users are to grips with the limitations and know
which potentially dangerous edge cases to avoid...

Chris

On 04/04/22 19:07, 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.

Having had a quick look at the book, one has to ask, what is the usp
over C ?. Looks quite similar to it, but more obscure just to be
different and more difficult to read...

Chris

<snipped>

On 04/06/22 22:04, Dan Cross wrote:
> In article<t2klgp$dm4$1@dont-email.me>,
> Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-04-06, Dan Cross<cross@spitfire.i.gajendra.net> wrote:
>>> In article<624d95fe$0$706$14726298@news.sunsite.dk>,
>>> Arne Vajhøj<arne@vajhoej.dk> wrote:
>>>> On 4/5/2022 2:05 PM, Simon Clubley wrote:
>>>>> It looks like Rust has come up with rather unique ways to screw up:
>>>>
>>>> I think you have a mysterious understanding of what is unique in
>>>> programming.
>>>>
>>>> (and this is not Rust as such but libraries written in Rust)
>>>
>>> Indeed. I read that quip as a statement along the lines of,
>>> "tell me you don't know Rust without telling me that you don't
>>> know Rust."
>>
>> Actually, both of you have missed the point.
>
> I'm afraid your point is based on either confusion or lack of
> familiarity.
>
>> My point is that this all-new all-singing programming language that
>> will save us all (according to its creators) is released with all
>> these new and unique features that make Rust better than anything
>> else out there for security (also according to its creators).
>
> I invite you to provide a citation to one of the Rust creators
> making such a claim.
>
> Again, these people aren't fools: they understand that no one
> language is the One True Solution to All Problems. The people
> who designed and implemented Rust are actually qualified PL
> people. You seemed to have glombed onto the fan boys pitching
> hype and somehow think that's representative of the folks
> actually doing the work: it is not.
>
>> People then start using this language to create libraries and manage
>> to still write code that compromises these new safety features, hence
>> making the library unsafe, but unsafe in a way that is unique to Rust
>> because it manages to violate the guarantees that the language says
>> it gives you.
>>
>> And before you say it, I know Rust is not unique in this and that is
>> exactly the point. Just as you have to do when writing code in other
>> programming languages, you still have to know what you are doing when
>> writing Rust code or you can still write code that has security issues
>> within it.
>
> No one serious ever claimed otherwise.
>
>> And my attitude-free serious point is this: Rust brings some new ideas
>> to the table and they are ideas that are worth exploring. But at the
>> end of the day, it's just another tool with some more features built in
>> that can help you write more secure code and make it harder for you
>> to screw up.
>
> Perhaps if you eliminated the hyperbole elsewhere and just lead
> with this, you'd find that it gets a better reception.
>
>> Unfortunately, listening to people pushing the general Rust hype, they
>> would have you believe that Rust is some super-language that will instantly
>> solve all your security problems, even in code written by novices, if you
>> just start writing code in it and manage to get your code to compile.
>
> No one serious has ever claimed that.
>
>> That's not true and it's not true for any language that we have created.
>> It's just that there are some languages out there that make it a _lot_
>> harder to screw up in than in other languages and for which you can write
>> much safer (NOTE: much safer, _not_ safe) code more easily.
>>
>> But you can still screw up even in those languages if you try hard enough
>> and if you don't really know what you are doing and that applies to all
>> languages we have ever created including both Ada and Rust.
>
> Again, no one credible ever claimed otherwise.
>
> - Dan C.
>

I don't like anything that claims or predisposes to protect me from
my own stupidity. Prefer the freedom to make my own mistakes and
learn from them. Not more nanny state, however fashionable it
may be...

Chris

On 04/06/22 00:46, Arne Vajhøj wrote:
> On 4/5/2022 9:04 AM, 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?
>
> (this is going to be a bit high level as I don't code in Rust)
>
> There is probably nothing that Rust can do that other languages
> can't do. Most stuff can be done in any language.
>
> But there may be some things where Rust is better than other
> languages.
>
> It is a modern language in the low level category.
>
> Modern means that it has looked at problems with older
> languages and tried to fix those.
>
> Low level makes it rare, because there are not many modern
> languages that are low level aka intended to be close to
> the metal and able to be used for OS and similar code.
>
> Go to high level code for business application and there
> are a ton of languages:
> * JVM languages - Java, Kotlin, Scala, Groovy
> * .NET languages - C#, VB.NET
> * JavaScript, TypeScript, Dart
> * PHP, Hack
> * modern C++
> * Python
> * Ruby
> and that is just the most widely used one - there are dozens more.
>
> For low level I can only think of two: Rust and Go. And they seem to
> have found different markets - the OS people like Rust and the
> container people like Go.
>
> C and C++ are currently dominating the low level code area, but
> there are some well known problem.
>
> Two of those problems are:
> * buffer overruns
> * memory leaks

Neither of those are the fault of the core language, but C library,
separate from the language. Man write their own library
functions to avoid that sort of issue.

What the C language provides, is the sharpest programming tool
in the box, just make sure you don't cut yourself. Personal
responsibility, not rule based order...

Chris

> Of course it is possible to write C and C++ code without risk
> of buffer overruns and memory leaks.
>
> But decades of experience shows that at scale like hiring 100
> average developers to write 1 million lines of code, then a
> number of those problems get introduced.
>
> Rust avoid those.
>
> Rust checks memory access *unless* in an unsafe block (idea borrowed
> from C# language). As a low level language Rust has the need to be able
> to do some flexible memory access - I can not imagine it is
> possible to write a device driver if only able to access memory
> in variables in the program.
>
> Rust has a unique approach to memory handling based on
> ownership (idea borrowed from modern C++ best practice
> not C++ language) that avoids memory leaks without GC - as
> a low level language that may be used in real time
> context, then the standard solution to avoid memory
> leaks in high level languages GC could be problematic.
>
> Arne
>

Rust as a high school language? I believe schools should be concentrating on
reading, writing and mathematics with special emphasis on the mathematics. I
can not believe that colleges need to offer remedial mathematics such as basic
algebra to their incoming freshmen. Writing should be a close second. Writing
as if "texting" friends is not composition.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 04/06/22 01:25, Dan Cross wrote:
> In article<jb43vkFbiv7U2@mid.individual.net>,
> Bill Gunshannon<bill.gunshannon@gmail.com> wrote:
>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>
>>> C and C++ are currently dominating the low level code area, but
>>> there are some well known problem.
>>>
>>> Two of those problems are:
>>> * buffer overruns
>>> * memory leaks
>>
>> Both those problems were fixed 40 years ago. The fixes were
>> ignored and the company offering Safe C went out of business.
>
> This is simply false. That there existed _one_ implementation
> that claimed to "fix" C 40 years ago does not mean that the
> problems with C were fixed.
>
> Moreover, buffer overruns and memory leaks are just two classes
> of problems that some implementations may have taken steps to
> fix. There are many, many others that more modern languages
> address: type incompatibilities, pointer safety, non-nullable
> reference types, well-defined ownership semantics, and many,
> many others.
>
> - Dan C.
>

This sounds like medication to cure everyone from their sloppy
programming. The infantilisation of complex subjects, just to give the
lazy an easier time, while still getting the product built.
The answer to that is not languages that constrain movement, but
developing more professional skills and applying due diligence
and attention to detail to system design and implementation.

I must be getting old, so what happened to pursuit of excellence
and more ?...

Chris

On 4/6/2022 8:00 PM, chris wrote:
> On 04/06/22 01:25, Dan Cross wrote:
>> In article<jb43vkFbiv7U2@mid.individual.net>,
>> Bill Gunshannon<bill.gunshannon@gmail.com>  wrote:
>>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>>
>>>> C and C++ are currently dominating the low level code area, but
>>>> there are some well known problem.
>>>>
>>>> Two of those problems are:
>>>> * buffer overruns
>>>> * memory leaks
>>>
>>> Both those problems were fixed 40 years ago.  The fixes were
>>> ignored and the company offering Safe C went out of business.
>>
>> This is simply false.  That there existed _one_ implementation
>> that claimed to "fix" C 40 years ago does not mean that the
>> problems with C were fixed.
>>
>> Moreover, buffer overruns and memory leaks are just two classes
>> of problems that some implementations may have taken steps to
>> fix.  There are many, many others that more modern languages
>> address: type incompatibilities, pointer safety, non-nullable
>> reference types, well-defined ownership semantics, and many,
>> many others.
>
> This sounds like medication to cure everyone from their sloppy
> programming. The infantilisation of complex subjects, just to give the
> lazy an easier time, while still getting the product built.
> The answer to that is not languages that constrain movement, but
> developing more professional skills and applying due diligence
> and attention to detail to system design and implementation.
>
> I must be getting old, so what happened to pursuit of excellence
> and more ?...

If one believe it is the morally best to make results
clearly reflect the difference between good and bad
programmers then that makes sense.

But businesses does not exist to pursue such moral
goals. Businesses exist to make money. The reality
is that there are good, mediocre and bad programmers
out there. Businesses want the tools that enable
all their developers to be productive. So tools
preventing the bad programmers from shooting
themselves in the foot is good business.

Arne

On 4/6/2022 7:46 PM, chris wrote:
> On 04/06/22 00:46, Arne Vajhøj wrote:
>> C and C++ are currently dominating the low level code area, but
>> there are some well known problem.
>>
>> Two of those problems are:
>> * buffer overruns
>> * memory leaks
>
> Neither of those are the fault of the core language, but C library,
> separate from the language. Man write their own library
> functions to avoid that sort of issue.

That is not correct.

Those problems cannot be solved by library changes.

Unchecked array access does not include any library
functions.

And both GC and the more exotic ownership concept
requires more than library changes - it requires language
and runtime environment (which is not the same as
runtime library) changes.

Arne

On 4/6/2022 6:51 PM, VAXman-@SendSpamHere.ORG wrote:
> Rust as a high school language? I believe schools should be concentrating on
> reading, writing and mathematics with special emphasis on the mathematics. I
> can not believe that colleges need to offer remedial mathematics such as basic
> algebra to their incoming freshmen. Writing should be a close second. Writing
> as if "texting" friends is not composition.

Not sure how this topic got into this thread, but whatever.

The idea about teaching programming in secondary or primary school
come up frequently.

Mostly from people that don't know programming.

I don't think it make any sense. The available time will be
so small and the level taught so low that it will not be
useful. It does not provide the IT industry with something
they can use. And it does not provide any valuable skills to
the students.

So I concur: reading, writing and math.

Maybe a few foreign languages!!

Arne

On Wednesday, April 6, 2022 at 5:01:02 PM UTC-7, chris wrote:
> On 04/06/22 01:25, Dan Cross wrote:
> > In article<jb43vk...@mid.individual.net>,
> > Bill Gunshannon<bill.gu...@gmail.com> wrote:
> >> On 4/5/22 19:46, Arne Vajhøj wrote:
> >>>
> >>> C and C++ are currently dominating the low level code area, but
> >>> there are some well known problem.
> >>>
> >>> Two of those problems are:
> >>> * buffer overruns
> >>> * memory leaks
> >>
> >> Both those problems were fixed 40 years ago. The fixes were
> >> ignored and the company offering Safe C went out of business.
> >
> > This is simply false. That there existed _one_ implementation
> > that claimed to "fix" C 40 years ago does not mean that the
> > problems with C were fixed.
> >
> > Moreover, buffer overruns and memory leaks are just two classes
> > of problems that some implementations may have taken steps to
> > fix. There are many, many others that more modern languages
> > address: type incompatibilities, pointer safety, non-nullable
> > reference types, well-defined ownership semantics, and many,
> > many others.
> >
> > - Dan C.
> >
>
> This sounds like medication to cure everyone from their sloppy
> programming. The infantilisation of complex subjects, just to give the
> lazy an easier time, while still getting the product built.
> The answer to that is not languages that constrain movement, but
> developing more professional skills and applying due diligence
> and attention to detail to system design and implementation.
>
> I must be getting old, so what happened to pursuit of excellence
> and more ?...
>
> Chris

It's a question of provability. No current C project can implement the kind of toolchain that duplicates the compiler's static analysis proofs. And we haven't gotten to its runtime proofs. When combined with its runtime guarantees, it is a significant step forward.
The compiler is only one part of Rust's toolchain, but that's another story..

Here's a car analogy: do you want to change a tire using a power tool or good ol' muscles?

If by chance we see this language on VMS within our lifetimes, we should be prepared. We'd be unstoppable.

On 2022-04-06, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t2klgp$dm4$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>My point is that this all-new all-singing programming language that
>>will save us all (according to its creators) is released with all
>>these new and unique features that make Rust better than anything
>>else out there for security (also according to its creators).
>
> I invite you to provide a citation to one of the Rust creators
> making such a claim.
>
> Again, these people aren't fools: they understand that no one
> language is the One True Solution to All Problems. The people
> who designed and implemented Rust are actually qualified PL
> people. You seemed to have glombed onto the fan boys pitching
> hype and somehow think that's representative of the folks
> actually doing the work: it is not.
>

That last bit may be possible.

I don't know how old you are Dan, but I'm old enough to have gone
through the early years of Java and the insane levels of hype that
were being generated about Java during those days before things
settled down and much of it _was_ revealed to be hype.

The insane levels of promotion of Rust as "the" solution at the moment
remind me of those days.

>>People then start using this language to create libraries and manage
>>to still write code that compromises these new safety features, hence
>>making the library unsafe, but unsafe in a way that is unique to Rust
>>because it manages to violate the guarantees that the language says
>>it gives you.
>>
>>And before you say it, I know Rust is not unique in this and that is
>>exactly the point. Just as you have to do when writing code in other
>>programming languages, you still have to know what you are doing when
>>writing Rust code or you can still write code that has security issues
>>within it.
>
> No one serious ever claimed otherwise.
>

I note your "no one serious" qualifier. :-)

Sometimes, looking in from the outside, it's hard/impossible to tell
the difference.

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-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/6/2022 6:51 PM, VAXman-@SendSpamHere.ORG wrote:
>> Rust as a high school language? I believe schools should be concentrating on
>> reading, writing and mathematics with special emphasis on the mathematics. I
>> can not believe that colleges need to offer remedial mathematics such as basic
>> algebra to their incoming freshmen. Writing should be a close second. Writing
>> as if "texting" friends is not composition.
>
> Not sure how this topic got into this thread, but whatever.
>

It got into this thread because Simon wrote "HS" instead of "HA" in
the title. Sorry. :-)

> The idea about teaching programming in secondary or primary school
> come up frequently.
>
> Mostly from people that don't know programming.
>
> I don't think it make any sense. The available time will be
> so small and the level taught so low that it will not be
> useful. It does not provide the IT industry with something
> they can use. And it does not provide any valuable skills to
> the students.
>

Back when I was in secondary school (early 1980s) programming classes
_were_ along the subjects offered. Basic was the language in use but
I also came across this new language called Fortran and started doing
the assignments in that language as well as in Basic just for fun. :-)

And you are wrong Arne in an important way. You don't get any direct
skills that you can use in industry but it exposes students to what
is involved in writing programs and the mindset required.

It became obvious to me very quickly that this was something I _really_
liked and made me consider it as my possible future (which obviously
turned into reality).

Simon.

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

On 4/6/22 12:35, Arne Vajhøj wrote:
> On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
>> On 4/5/22 20:20, Arne Vajhøj wrote:
>>> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
>>>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>>> C and C++ are currently dominating the low level code area, but
>>>>> there are some well known problem.
>>>>>
>>>>> Two of those problems are:
>>>>> * buffer overruns
>>>>> * memory leaks
>>>>
>>>> Both those problems were fixed 40 years ago.  The fixes were
>>>> ignored and the company offering Safe C went out of business.
>>>
>>> They were not fixed as the current C compilers allow
>>> the problems.
>>>
>>> Maybe they could have been fixed, but that does not really
>>> help those with C code today.
>>
>> Let me re-word that.  40 years ago the problems were well known
>> and documented.  A company created a C compiler and support package
>> to fix it.  The industry rejected it because the cost (and I don't
>> mean the purchase price!) was too high.
>>
>> It is interesting that very little of this made it into the C
>> Standard which is when they could have fixed all of it.  And
>> they can't use the backwards compatibility argument because
>> there was no compatibility maintained between K&R and ANSI C.
>
> How much is known about why that product failed?

Today, little more than memories. I don't imagine Don French is
still around to ask but when the subject was discussed more than
20 years ago the general understanding was that the overhead was
much more than users were willing to put up with. Another example
of something ahead of its time. (Like the UCSD P-machine and the
STVOS.)

>
> I could have been the overhead. But I doubt it. Many languages
> from that era did either check or had the option of enabling checks.

And many did not. COBOL never did precisely because of the overhead.
(Not sure if it does it today.) Fortran may have been weak in this
respect as I can remember working on a lot of programs where the
solution seemed to hint at bounds problems. Pascal seemed to always
have the option to turn all of it off. I think the intent was to
develop with it on and then turn it off for the performance value
when ready for production. (Again remembering that production was
never Wirth's purpose for the language!)

>
> And today it would almost certainly not have been an issue. Most
> languages check.

And yet, C still doesn't even after ANSI got control of it. I am
now curious about COBOL, though. I wonder if I can find the deck
from my demo program from the classroom in 1980?

bill

On 4/6/22 17:20, Dan Cross wrote:
> In article <jb5s77FlsqfU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 4/5/22 20:20, Arne Vajhøj wrote:
>>> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
>>>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>>> C and C++ are currently dominating the low level code area, but
>>>>> there are some well known problem.
>>>>>
>>>>> Two of those problems are:
>>>>> * buffer overruns
>>>>> * memory leaks
>>>>
>>>> Both those problems were fixed 40 years ago.  The fixes were
>>>> ignored and the company offering Safe C went out of business.
>>>
>>> They were not fixed as the current C compilers allow
>>> the problems.
>>>
>>> Maybe they could have been fixed, but that does not really
>>> help those with C code today.
>>
>> Let me re-word that. 40 years ago the problems were well known
>> and documented.
>
> No. Entire new classes of problems have emerged in those 40
> years, and you have and continue to ignore those. It's not
> _just_ array bounds and memory leaks that are at issue.
>

Safe C addressed a lot more than that. I just mentioned the two you
hear the most complaints about. The entire list is more than I have
the inclination to sit here and type in by hand from the PDP-11
Software Source Book. Oh, and re-reading the description, it appears
there was also a version available for the VAX. Wonder why VMS didn't
pick up on this?

bill

bill

On 4/7/2022 8:31 AM, Simon Clubley wrote:
> On 2022-04-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/6/2022 6:51 PM, VAXman-@SendSpamHere.ORG wrote:
>>> Rust as a high school language? I believe schools should be concentrating on
>>> reading, writing and mathematics with special emphasis on the mathematics. I
>>> can not believe that colleges need to offer remedial mathematics such as basic
>>> algebra to their incoming freshmen. Writing should be a close second. Writing
>>> as if "texting" friends is not composition.
>>
>> Not sure how this topic got into this thread, but whatever.
>>
>
> It got into this thread because Simon wrote "HS" instead of "HA" in
> the title. Sorry. :-)
>
>> The idea about teaching programming in secondary or primary school
>> come up frequently.
>>
>> Mostly from people that don't know programming.
>>
>> I don't think it make any sense. The available time will be
>> so small and the level taught so low that it will not be
>> useful. It does not provide the IT industry with something
>> they can use. And it does not provide any valuable skills to
>> the students.
>>
>
> Back when I was in secondary school (early 1980s) programming classes
> _were_ along the subjects offered. Basic was the language in use but
> I also came across this new language called Fortran and started doing
> the assignments in that language as well as in Basic just for fun. :-)
>
> And you are wrong Arne in an important way. You don't get any direct
> skills that you can use in industry but it exposes students to what
> is involved in writing programs and the mindset required.

Yes! This!

Instructing a dumb (but very fast) computer how to accomplish some task requires
some special ways of approaching the job. Some people "get it", some people
don't, and early exposure to the techniques can be helpful.

> It became obvious to me very quickly that this was something I _really_
> liked and made me consider it as my possible future (which obviously
> turned into reality).
>
> Simon.
>

--
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/7/22 10:02, Dave Froble wrote:
>
>
> Instructing a dumb (but very fast) computer how to accomplish some task
> requires some special ways of approaching the job.  Some people "get
> it", some people don't, and early exposure to the techniques can be
> helpful.

My experience in academia doesn't agree. We have had students come in
with "experience" and "Computer Science Education" prior to the start
of their college courses. (and many of them started with BASIC, usually
on an Apple) They have a higher likelihood of failing and dropping
out. Usually because they come in thinking they already know all about
it when in fact that never had the basics one should learn before they
write that first program. All this current craze for "coding" for
everyone down to pre-school does not bode well for the industry.

bill

On 04/07/22 02:00, Arne Vajhøj wrote:
> On 4/6/2022 7:46 PM, chris wrote:
>> On 04/06/22 00:46, Arne Vajhøj wrote:
>>> C and C++ are currently dominating the low level code area, but
>>> there are some well known problem.
>>>
>>> Two of those problems are:
>>> * buffer overruns
>>> * memory leaks
>>
>> Neither of those are the fault of the core language, but C library,
>> separate from the language. Man write their own library
>> functions to avoid that sort of issue.
>
> That is not correct.
>
> Arne

What part of that is incorrect ?.

> Those problems cannot be solved by library changes.
>
> Unchecked array access does not include any library
> functions.

Well, pointers are dangerous in careless hands, but
you don't try to make them less so by constraining their
use. Seems to me, all efforts in that direction end up
limiting choices and tend to funnel design direction
into narrow, inflexible pathways. Some like that and
may even think they need it, but not here.

As I hinted, it depends how much a language should hold
your hand to try and prevent errors. Prefer the freedom
to make my own choices and the maximum freedom to make
them, within the law, of course. For a programming
language, that law means the specification.

>
> And both GC and the more exotic ownership concept
> requires more than library changes - it requires language
> and runtime environment (which is not the same as
> runtime library) changes.
>

Assume we were talking about C here, which has no GC in
the design. C++ perhaps, but that's a whole other can of
worms....

Chris

In article <t2l638$17rl$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/06/22 01:27, Dan Cross wrote:
>> In article<624cdd77$0$704$14726298@news.sunsite.dk>,
>> Arne Vajhøj<arne@vajhoej.dk> wrote:
>>> On 4/5/2022 8:21 PM, Dan Cross wrote:
>>>> In article<t2ilf1$18mj$1@gioia.aioe.org>,
>>>> chris<chris-nospam@tridac.net> wrote:
>>>>> I think the point is that languages take time to evolve and the path
>>>>> can be unstable until there is enough critical mass to produce a fully
>>>>> documented and standard version. I would expect that to take a decade
>>>>> or more. No good for serious work without that professionalism. Toy
>>>>> and experimental otherwise.
>>>>
>>>> Java doesn't have a "standard" in the sense described here, but
>>>> much as I don't care for it as a language I'd be hard pressed to
>>>> describe it as a "toy" or "no good for serious work."
>>>
>>> Java is not ISO/ANSI/ECMA standardized.
>>>
>>> But the JCP process is really very similar to ISO/ANSI/ECMA.
>>
>> Sounds kind of like the Rust RFC process, but some posters here
>> seem to have suggested that without a document produced under
>> the auspicies of a relevant standards body, a language is not
>> viable for serious work.
>
>I wasn't suggesting that, but it takes years for all the issues
>to be resolved and a language to become mature. That and the
>language tends to be more fully documented formally. Sure, there
>are always issues, but C has been around for long enough now that
>most skilled users are to grips with the limitations and know
>which potentially dangerous edge cases to avoid...

That's demonstrably not true. C has become a tricky language,
one where most people who claim to be "skilled C programmers"
and who "know which potentially dangerous edge cases to avoid"
are either compiler writers, or deluding themselves.

PS: Rust will be 12 years old this year, but dates back to 2006.

- Dan C.

In article <t2l82r$1s8o$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>I don't like anything that claims or predisposes to protect me from
>my own stupidity. Prefer the freedom to make my own mistakes and
>learn from them. Not more nanny state, however fashionable it
>may be...

Seatbelts are for wimps, I guess. There's lots to be learned
being thrown through the windshield of a moving car.

- Dan C.

In article <t2mkq4$ib9$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-06, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2klgp$dm4$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>>My point is that this all-new all-singing programming language that
>>>will save us all (according to its creators) is released with all
>>>these new and unique features that make Rust better than anything
>>>else out there for security (also according to its creators).
>>
>> I invite you to provide a citation to one of the Rust creators
>> making such a claim.
>>
>> Again, these people aren't fools: they understand that no one
>> language is the One True Solution to All Problems. The people
>> who designed and implemented Rust are actually qualified PL
>> people. You seemed to have glombed onto the fan boys pitching
>> hype and somehow think that's representative of the folks
>> actually doing the work: it is not.
>
>That last bit may be possible.
>
>I don't know how old you are Dan, but I'm old enough to have gone
>through the early years of Java and the insane levels of hype that
>were being generated about Java during those days before things
>settled down and much of it _was_ revealed to be hype.

I'm old enough to remember that, as well. Indeed, I read a
pre-alpha Java spec and thought it was pretty nifty at the time.
Then the snakeoil "Uncle Bob" types got a hold of it and it
became a bloated mess.

>The insane levels of promotion of Rust as "the" solution at the moment
>remind me of those days.

I wonder where you are seeing that. Seriously. I know and/or
have worked with a number of members of the Rust community for
several years (members of the core, language, and tool teams,
for about 3 years), and they're quite gracious in admitting that
it's not the right solution for everything.

>>>People then start using this language to create libraries and manage
>>>to still write code that compromises these new safety features, hence
>>>making the library unsafe, but unsafe in a way that is unique to Rust
>>>because it manages to violate the guarantees that the language says
>>>it gives you.
>>>
>>>And before you say it, I know Rust is not unique in this and that is
>>>exactly the point. Just as you have to do when writing code in other
>>>programming languages, you still have to know what you are doing when
>>>writing Rust code or you can still write code that has security issues
>>>within it.
>>
>> No one serious ever claimed otherwise.
>
>I note your "no one serious" qualifier. :-)
>
>Sometimes, looking in from the outside, it's hard/impossible to tell
>the difference.

Yes, well. Like with all things, one cannot control people who
want to say outrageous things. However, after a certain time in
the industry, one usually learns to identify those people and,
well, ignore them.

With respect to Rust, I feel myself very fortunate to have come
at it from a _very_ skeptical perspective. I was just tired of
writing kernel code in C, and while I looked at Rust and said,
"big, ugly language" I gave it a shot anyway because it had a
minimal runtime and was easy to get going on bare metal. I'm
pleased I did.

- Dan C.