"White House to Developers: Using C or C++ Invites Cybersecurity Risks"
https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks

"The Biden administration backs a switch to more memory-safe programming
languages. The tech industry sees their point, but it won't be easy."

No. The feddies want to regulate software development very much. They
have been talking about it for at least 20 years now. This is a very
bad thing.

Lynn

On Sat, 2 Mar 2024 17:13:56 -0600, Lynn McGuire wrote:

> The feddies want to regulate software development very much.

Given the high occurrence of embarrassing mistakes companies have been
making with their code, and continue to make, it’s quite clear they’re not
capable of regulating this issue themselves.

I wouldn’t worry about companies tripping over and hurting themselves, but
when the consequences are security leaks, not of information belonging to
those companies, but to their innocent customers/users who are often
unaware that those companies even had that information, then it’s quite
clear that Government has to step in.

Because if they don’t, then who will?

trimmed followups to comp.lang.c

In comp.lang.c Lynn McGuire <lynnmcguire5@gmail.com> wrote:
<snip>
>
> "The Biden administration backs a switch to more memory-safe programming
> languages. The tech industry sees their point, but it won't be easy."
>
> No. The feddies want to regulate software development very much. They
> have been talking about it for at least 20 years now. This is a very
> bad thing.

Well to be fair, the feds regulations in the 60s made COBOL and
FORTRAN very popular, plus POSIX later on. All they did was
say "we will not buy anything unless ... rules".

From "The C Programming Language Quotes by Brian W. Kernighan".

> Nevertheless, C retains the basic philosophy that
> programmers know what they are doing; it only requires
> that they state their intentions explicitly.

If programmers were given time to test and develop, many
issues would not exist. Anyone who has ever worked for a
large company knows the pressure that exists to get things
done quickly instead of right. So all these issues I blame
on management.

How many times have we heard "ship it now, you can fix later"
and "later" never comes. :)

Rust will never fix policy issues, just different and maybe worst
issues will happen.

> Lynn

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On Sun, 3 Mar 2024 02:10:03 -0000 (UTC), John McCue wrote:

> Well to be fair, the feds regulations in the 60s made COBOL and FORTRAN
> very popular, plus POSIX later on.

The US Government purchasing rules on POSIX were sufficiently sketchy that
Microsoft was able to satisfy them easily with Windows NT, while supplying
a “POSIX” subsystem that was essentially unusable.

And then Microsoft went on to render POSIX largely irrelevant by eating
all the proprietary “Unix” vendors alive.

Nowadays, POSIX (and *nix generally) is undergoing a resurgence because of
Linux and Open Source. Developers are discovering that the Linux ecosystem
offers a much more productive development environment for a code-sharing,
code-reusing, Web-centric world than anything Microsoft can offer.

Any attempt to displace C will require total replacement of the modern
computing ecosystem. Frankly, i'd be fine with that if pulled off well,
but i wouldn't be fine with a half-baked solution nor trying to force out
C without thinking about the whole rest of everything.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Mac and Cheese, Horrifying Quality, Prepared by Barack Obama

Lawrence D'Oliveiro wrote:

> Nowadays, POSIX (and *nix generally) is undergoing a resurgence because
> of Linux and Open Source. Developers are discovering that the Linux
> ecosystem offers a much more productive development environment for a
> code-sharing, code-reusing, Web-centric world than anything Microsoft
> can offer.

I do not want to live in a web-centric world. I would much rather see
other, better uses of the internet become widespread.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Special thanks to misinformed hipsters!

On Sat, 2 Mar 2024 17:13:56 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> They have been talking about it for at least 20 years now.

More like 48-49 years.
https://en.wikipedia.org/wiki/High_Order_Language_Working_Group

On 03/03/2024 00:13, Lynn McGuire wrote:
> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>
> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>
> "The Biden administration backs a switch to more memory-safe programming
> languages. The tech industry sees their point, but it won't be easy."
>
> No.  The feddies want to regulate software development very much.  They
> have been talking about it for at least 20 years now.  This is a very
> bad thing.
>
> Lynn

It's the wrong solution to the wrong problem.

It is not languages like C and C++ that are "unsafe". It is the
programmers that write the code for them. As long as the people
programming in Rust or other modern languages are the more capable and
qualified developers - the ones who think about memory safety, correct
code, testing, and quality software development - then code written in
Rust will be better quality and safer than the average C, C++, Java and
C# code.

But if it gets popular enough for schools and colleges to teach Rust
programming course to the masses, and it gets used by developers who are
paid per KLoC, given responsibilities well beyond their abilities and
experience, lead by incompetent managers, untrained in good development
practices and pushed to impossible deadlines, then the average quality
of programs in Rust will drop to that of average C and C++ code.

Good languages and good tools help, but they are not the root cause of
poor quality software in the world.

On 03.03.2024 12:01, David Brown wrote:
> On 03/03/2024 00:13, Lynn McGuire wrote:
>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>
>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>
>> "The Biden administration backs a switch to more memory-safe
>> programming languages. [...]"
>> [...]
>
> It's the wrong solution to the wrong problem.
>
> It is not languages like C and C++ that are "unsafe". It is the
> programmers that write the code for them. [...]
>
> [...]
>
> Good languages and good tools help, but they are not the root cause of
> poor quality software in the world.

I agree about the necessity of having good programmers. But a lot more
factors are important, and there's factors that influence programmers.
Languages may have a design that makes it possible to produce safer
software, or to be error prone and require a lot more attention from
the programmers (and also from management). Tools may help a bit to
work around the problems that languages inherently add. Good project
management may also help to increase software quality. But it's much
more costly in case of using inferior (or unsuited) languages.

Janis

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>"White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>
>https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>
>"The Biden administration backs a switch to more memory-safe programming
>languages. The tech industry sees their point, but it won't be easy."
>
>No. The feddies want to regulate software development very much.

You've been reading far to much apocalyptic fiction and seeing the
world through trump-colored glasses. Neither reflect reality.

On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote:
> On 03/03/2024 00:13, Lynn McGuire wrote:
>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>
>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>
>> "The Biden administration backs a switch to more memory-safe programming
>> languages. The tech industry sees their point, but it won't be easy."
>>
>> No.  The feddies want to regulate software development very much.  They
>> have been talking about it for at least 20 years now.  This is a very
>> bad thing.
>>
>> Lynn
>
> It's the wrong solution to the wrong problem.
>
> It is not languages like C and C++ that are "unsafe". It is the
> programmers that write the code for them. As long as the people
> programming in Rust or other modern languages are the more capable and
> qualified developers - the ones who think about memory safety, correct
> code, testing, and quality software development - then code written in
> Rust will be better quality and safer than the average C, C++, Java and
> C# code.

Programmers who think about safety, correctness and quality and all that
have way fewer diagnostics and more footguns if they are coding in C
compared to Rust.

I think, you can't just wave away the characteristics of Rust as making
no difference in this regard.

> But if it gets popular enough for schools and colleges to teach Rust
> programming course to the masses, and it gets used by developers who are
> paid per KLoC, given responsibilities well beyond their abilities and
> experience, lead by incompetent managers, untrained in good development
> practices and pushed to impossible deadlines, then the average quality
> of programs in Rust will drop to that of average C and C++ code.

The rhetoric you hear from Rust people about this is that coders taking
a safety shortcut to make something work have to explicitly ask for that
in Rust. It leaves a visible trace. If something goes wrong because of
an unsafe block, you can trace that to the commit which added it.

The rhetoric all sounds good.

However, like you, I also believe it boils down to people, in a
somewhat different way. To use Rust productively, you have to be one of
the rare idiot savants who are smart enough to use it *and* numb to all
the inconveniences.

The reason the average programmer won't make any safety
boo-boos using Rust is that the average programmer either isn't smart
enough to use it at all, or else doesn't want to put up with the fuss:
they will opt for some safe language which is easy to use.

Rust's problem is that we have safe languages in which you can almost
crank out working code with your eyes closed. (Or if not working,
then at least code in which the only uncaught bugs are your logic bugs,
not some undefined behavior from integer overflow or array out of
bounds.)

This is why Rust people are desperately pitching Rust as an alternative
for C and whatnot, and showcasing it being used in the kernel and
whatnot.

Trying to be both safe and efficient to be able to serve as a "C
replacement" is a clumsy hedge that makes Rust an awkward language.

You know the parable about the fox that tries to chase two rabbits.

The alternative to Rust in application development is pretty much any
convenient, "easy" high level language, plus a little bit of C.
You can get a small quantity of C right far more easily than a large
quantity of C. It's almost immaterial.

An important aspect of Rust is the ownership-based memory management.

The problem is, the "garbage collection is bad" era is /long/ behind us.

Scoped ownership is a half-baked solution to the object lifetime
problem, that gets in the way of the programmer and isn't appropriate
for the vast majority of software tasks.

Embedded systems often need custom memory management, not something that
the language imposes. C has malloc, yet even that gets disused in favor
of something else.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:

> It is not languages like C and C++ that are "unsafe".

Some empirical evidence from Google
<https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
shows a reduction in memory-safety errors in switching from C/C++ to Rust.

On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:

> Lawrence D'Oliveiro wrote:
>
>> Nowadays, POSIX (and *nix generally) is undergoing a resurgence because
>> of Linux and Open Source. Developers are discovering that the Linux
>> ecosystem offers a much more productive development environment for a
>> code-sharing, code-reusing, Web-centric world than anything Microsoft
>> can offer.
>
> I do not want to live in a web-centric world.

You already do.

On 03/03/2024 19:18, Kaz Kylheku wrote:
> On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote:
>> On 03/03/2024 00:13, Lynn McGuire wrote:
>>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>>
>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>>
>>> "The Biden administration backs a switch to more memory-safe programming
>>> languages. The tech industry sees their point, but it won't be easy."
>>>
>>> No.  The feddies want to regulate software development very much.  They
>>> have been talking about it for at least 20 years now.  This is a very
>>> bad thing.
>>>
>>> Lynn
>>
>> It's the wrong solution to the wrong problem.
>>
>> It is not languages like C and C++ that are "unsafe". It is the
>> programmers that write the code for them. As long as the people
>> programming in Rust or other modern languages are the more capable and
>> qualified developers - the ones who think about memory safety, correct
>> code, testing, and quality software development - then code written in
>> Rust will be better quality and safer than the average C, C++, Java and
>> C# code.
>
> Programmers who think about safety, correctness and quality and all that
> have way fewer diagnostics and more footguns if they are coding in C
> compared to Rust.
>
> I think, you can't just wave away the characteristics of Rust as making
> no difference in this regard.

I did not.

I said that the /root/ problem is not the language, but the programmers
and the way they work.

Of course some languages make some things harder and other things
easier. And even the most careful programmers will occasionally make
mistakes. So having a language that helps reduce the risk of some kinds
of errors is a helpful thing.

But consider this. When programming in modern C++, you can be risk-free
from buffer overruns and most kinds of memory leak - use container
classes, string classes, and the like, rather than C-style arrays and
malloc/free or new/delete. You can use the C++ coding guideline
libraries to mark ownership of pointers. You can use compiler
sanitizers to catch many kinds undefined behaviour. You can use all
sorts of static analysis tools, from free to very costly, to help find
problems. And yet there are armies of programmers writing bad C++ code.
PHP and Javascript have automatic memory management and garbage
collection eliminating many of the possible problems seen in C and C++
code, yet armies of programmers write PHP and Javascript code full of
bugs and security faults.

Better languages, better libraries, and better tools certainly help.
There are not many tasks for which C is the best choice of language.
But none of that will deal with the root of the problem. Good
programmers, with good training, in good development departments with
good managers and good resources, will write correct code more
efficiently in a better language, but they can write correct code in
pretty much /any/ language. Similarly, the bulk of programmers will
write bad code in any language.

>
>> But if it gets popular enough for schools and colleges to teach Rust
>> programming course to the masses, and it gets used by developers who are
>> paid per KLoC, given responsibilities well beyond their abilities and
>> experience, lead by incompetent managers, untrained in good development
>> practices and pushed to impossible deadlines, then the average quality
>> of programs in Rust will drop to that of average C and C++ code.
>
> The rhetoric you hear from Rust people about this is that coders taking
> a safety shortcut to make something work have to explicitly ask for that
> in Rust. It leaves a visible trace. If something goes wrong because of
> an unsafe block, you can trace that to the commit which added it.
>
> The rhetoric all sounds good.

You can't trace the commit for programmers who don't use version control
software - and that is a /lot/ of them. Leaving visible traces does not
help when no one else looks at the code. Shortcuts are taken because
the sales people need the code by tomorrow morning, and there are only
so many hours in the night to get it working.

Rust makes it possible to have some safety checks for a few things that
are much harder to do in C++. It does not stop people writing bad code
using bad development practices.

>
> However, like you, I also believe it boils down to people, in a
> somewhat different way. To use Rust productively, you have to be one of
> the rare idiot savants who are smart enough to use it *and* numb to all
> the inconveniences.

And you have to have managers who are smart enough to believe it when
their programmers say they need to train in a new language, re-write
lots of existing code, and accept longer development times as a tradeoff
for fewer bugs in shipped code.

(I personally have a very good manager, but I know a great many
programmers do not.)

>
> The reason the average programmer won't make any safety
> boo-boos using Rust is that the average programmer either isn't smart
> enough to use it at all, or else doesn't want to put up with the fuss:
> they will opt for some safe language which is easy to use.
>
> Rust's problem is that we have safe languages in which you can almost
> crank out working code with your eyes closed. (Or if not working,
> then at least code in which the only uncaught bugs are your logic bugs,
> not some undefined behavior from integer overflow or array out of
> bounds.)
>
> This is why Rust people are desperately pitching Rust as an alternative
> for C and whatnot, and showcasing it being used in the kernel and
> whatnot.
>

I personally think it is madness to have Rust in a project like the
Linux kernel. I used to see C++ as a rapidly changing language with its
3 year cycle - Rust seems to have a 3 week cycle for updates, with no
formal standardisation and "work in progress" attitude. That's fine for
a new language under development, but /not/ something you want for a
project that spans decades.

> Trying to be both safe and efficient to be able to serve as a "C
> replacement" is a clumsy hedge that makes Rust an awkward language.
>
> You know the parable about the fox that tries to chase two rabbits.
>
> The alternative to Rust in application development is pretty much any
> convenient, "easy" high level language, plus a little bit of C.
> You can get a small quantity of C right far more easily than a large
> quantity of C. It's almost immaterial.
>

There are lots of alternatives to Rust for application development. But
in general, higher level languages mean you do less manual work, and
write fewer lines of code for the same amount of functionality. And
that means a lower risk of errors.

> An important aspect of Rust is the ownership-based memory management.
>
> The problem is, the "garbage collection is bad" era is /long/ behind us.
>
> Scoped ownership is a half-baked solution to the object lifetime
> problem, that gets in the way of the programmer and isn't appropriate
> for the vast majority of software tasks.
>
> Embedded systems often need custom memory management, not something that
> the language imposes. C has malloc, yet even that gets disused in favor
> of something else.
>

For safe embedded systems, you don't want memory management at all.
Avoiding dynamic memory is an important aspect of safety-critical
embedded development.

Den 2024-03-03 skrev Lawrence D'Oliveiro <ldo@nz.invalid>:
> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>
>> It is not languages like C and C++ that are "unsafe".
>
> Some empirical evidence from Google
><https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
> shows a reduction in memory-safety errors in switching from C/C++ to Rust.

I'm not surprised. I think it is pretty self-evident that a language
that is designed to reduce memory errors, if correctly designed,
will do just that.

It is very easy to go on about good and bad programmers, but that
really doesn't matter since statistics from the real world show that
memory errors are common and cause serious vulnerabilities.

Considering how hostile today's interconnected world has become with
security getting a higher and higher priority, I think we are bound to
see a decline of memory unsafe languages. C++ can be written to be
memory safe, but it is also very easy to write C++ that is not memory
safe. If C++ is to stay competitive, I think the C++ committee needs
to have a good and long think about what can be done to remedy these
issues.

Doing nothing, I could see initiatives like CHERI introducing hardware
based memory safety being a saviour. If the languages that enforce
memory safety through their type system are more difficult to use, C++
might be preferable if the memory safety is provided more or less
transparently through the hardware. Although a software solution is
probably seen as easier and cheaper than a hardware one. As the sales
department at my last job informed me: "We can sell hardware, everyone
likes a shiny box! Software is supposed to be included for free!"

On 3/2/2024 4:05 PM, Lawrence D'Oliveiro wrote:
> On Sat, 2 Mar 2024 17:13:56 -0600, Lynn McGuire wrote:
>
>> The feddies want to regulate software development very much.
>
> Given the high occurrence of embarrassing mistakes companies have been
> making with their code, and continue to make, it’s quite clear they’re not
> capable of regulating this issue themselves.

Oh my. C/C++ compilers are banned world wide. They even have reeducation
camps that they will confine you to. You know, to learn the one true
way... If you make a bug using the one true way, you risk a firing
squad? lol. ;^)

>
> I wouldn’t worry about companies tripping over and hurting themselves, but
> when the consequences are security leaks, not of information belonging to
> those companies, but to their innocent customers/users who are often
> unaware that those companies even had that information, then it’s quite
> clear that Government has to step in.
>
> Because if they don’t, then who will?

lol.

On 3/3/2024 3:01 AM, David Brown wrote:
> On 03/03/2024 00:13, Lynn McGuire wrote:
>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>
>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>
>> "The Biden administration backs a switch to more memory-safe
>> programming languages. The tech industry sees their point, but it
>> won't be easy."
>>
>> No.  The feddies want to regulate software development very much.
>> They have been talking about it for at least 20 years now.  This is a
>> very bad thing.
>>
>> Lynn
>
> It's the wrong solution to the wrong problem.
>
> It is not languages like C and C++ that are "unsafe".  It is the
> programmers that write the code for them.  As long as the people
> programming in Rust or other modern languages are the more capable and
> qualified developers - the ones who think about memory safety, correct
> code, testing, and quality software development - then code written in
> Rust will be better quality and safer than the average C, C++, Java and
> C# code.

Then we will hear about how human programmers cannot be trusted... AI is
there. No programmers needed now. Jesting, of course, but I have heard
some people starting to think that way.

>
> But if it gets popular enough for schools and colleges to teach Rust
> programming course to the masses, and it gets used by developers who are
> paid per KLoC, given responsibilities well beyond their abilities and
> experience, lead by incompetent managers, untrained in good development
> practices and pushed to impossible deadlines, then the average quality
> of programs in Rust will drop to that of average C and C++ code.
>
> Good languages and good tools help, but they are not the root cause of
> poor quality software in the world.
>

On 3/3/2024 12:11 PM, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> Nowadays, POSIX (and *nix generally) is undergoing a resurgence because
>>> of Linux and Open Source. Developers are discovering that the Linux
>>> ecosystem offers a much more productive development environment for a
>>> code-sharing, code-reusing, Web-centric world than anything Microsoft
>>> can offer.
>>
>> I do not want to live in a web-centric world.
>
> You already do.

You are not an ai, right? ;^)

On 3/3/2024 12:23 PM, David Brown wrote:
> On 03/03/2024 19:18, Kaz Kylheku wrote:
>> On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote:
>>> On 03/03/2024 00:13, Lynn McGuire wrote:
>>>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>>>
>>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>>>
>>>> "The Biden administration backs a switch to more memory-safe
>>>> programming
>>>> languages. The tech industry sees their point, but it won't be easy."
>>>>
>>>> No.  The feddies want to regulate software development very much.  They
>>>> have been talking about it for at least 20 years now.  This is a very
>>>> bad thing.
>>>>
>>>> Lynn
>>>
>>> It's the wrong solution to the wrong problem.
>>>
>>> It is not languages like C and C++ that are "unsafe".  It is the
>>> programmers that write the code for them.  As long as the people
>>> programming in Rust or other modern languages are the more capable and
>>> qualified developers - the ones who think about memory safety, correct
>>> code, testing, and quality software development - then code written in
>>> Rust will be better quality and safer than the average C, C++, Java and
>>> C# code.
>>
>> Programmers who think about safety, correctness and quality and all that
>> have way fewer diagnostics and more footguns if they are coding in C
>> compared to Rust.
>>
>> I think, you can't just wave away the characteristics of Rust as making
>> no difference in this regard.
>
> I did not.
>
> I said that the /root/ problem is not the language, but the programmers
> and the way they work.
>
> Of course some languages make some things harder and other things
> easier.  And even the most careful programmers will occasionally make
> mistakes.  So having a language that helps reduce the risk of some kinds
> of errors is a helpful thing.
>
> But consider this.  When programming in modern C++, you can be risk-free
> from buffer overruns and most kinds of memory leak - use container
> classes, string classes, and the like, rather than C-style arrays and
> malloc/free or new/delete.  You can use the C++ coding guideline
> libraries to mark ownership of pointers.  You can use compiler
> sanitizers to catch many kinds undefined behaviour.  You can use all
> sorts of static analysis tools, from free to very costly, to help find
> problems.  And yet there are armies of programmers writing bad C++ code.
>  PHP and Javascript have automatic memory management and garbage
> collection eliminating many of the possible problems seen in C and C++
> code, yet armies of programmers write PHP and Javascript code full of
> bugs and security faults.
>
> Better languages, better libraries, and better tools certainly help.
> There are not many tasks for which C is the best choice of language. But
> none of that will deal with the root of the problem.  Good programmers,
> with good training, in good development departments with good managers
> and good resources, will write correct code more efficiently in a better
> language, but they can write correct code in pretty much /any/
> language.  Similarly, the bulk of programmers will write bad code in any
> language.
>
>>
>>> But if it gets popular enough for schools and colleges to teach Rust
>>> programming course to the masses, and it gets used by developers who are
>>> paid per KLoC, given responsibilities well beyond their abilities and
>>> experience, lead by incompetent managers, untrained in good development
>>> practices and pushed to impossible deadlines, then the average quality
>>> of programs in Rust will drop to that of average C and C++ code.
>>
>> The rhetoric you hear from Rust people about this is that coders taking
>> a safety shortcut to make something work have to explicitly ask for that
>> in Rust. It leaves a visible trace.  If something goes wrong because of
>> an unsafe block, you can trace that to the commit which added it.
>>
>> The rhetoric all sounds good.
>
> You can't trace the commit for programmers who don't use version control
> software - and that is a /lot/ of them.  Leaving visible traces does not
> help when no one else looks at the code.  Shortcuts are taken because
> the sales people need the code by tomorrow morning, and there are only
> so many hours in the night to get it working.
>
> Rust makes it possible to have some safety checks for a few things that
> are much harder to do in C++.  It does not stop people writing bad code
> using bad development practices.
>
>>
>> However, like you, I also believe it boils down to people, in a
>> somewhat different way. To use Rust productively, you have to be one of
>> the rare idiot savants who are smart enough to use it *and* numb to all
>> the inconveniences.
>
> And you have to have managers who are smart enough to believe it when
> their programmers say they need to train in a new language, re-write
> lots of existing code, and accept longer development times as a tradeoff
> for fewer bugs in shipped code.
>
> (I personally have a very good manager, but I know a great many
> programmers do not.)
>
>>
>> The reason the average programmer won't make any safety
>> boo-boos using Rust is that the average programmer either isn't smart
>> enough to use it at all, or else doesn't want to put up with the fuss:
>> they will opt for some safe language which is easy to use.
>>
>> Rust's problem is that we have safe languages in which you can almost
>> crank out working code with your eyes closed. (Or if not working,
>> then at least code in which the only uncaught bugs are your logic bugs,
>> not some undefined behavior from integer overflow or array out of
>> bounds.)
>>
>> This is why Rust people are desperately pitching Rust as an alternative
>> for C and whatnot, and showcasing it being used in the kernel and
>> whatnot.
>>
>
> I personally think it is madness to have Rust in a project like the
> Linux kernel.  I used to see C++ as a rapidly changing language with its
> 3 year cycle - Rust seems to have a 3 week cycle for updates, with no
> formal standardisation and "work in progress" attitude.  That's fine for
> a new language under development, but /not/ something you want for a
> project that spans decades.
>
>> Trying to be both safe and efficient to be able to serve as a "C
>> replacement" is a clumsy hedge that makes Rust an awkward language.
>>
>> You know the parable about the fox that tries to chase two rabbits.
>>
>> The alternative to Rust in application development is pretty much any
>> convenient, "easy" high level language, plus a little bit of C.
>> You can get a small quantity of C right far more easily than a large
>> quantity of C. It's almost immaterial.
>>
>
> There are lots of alternatives to Rust for application development.  But
> in general, higher level languages mean you do less manual work, and
> write fewer lines of code for the same amount of functionality.  And
> that means a lower risk of errors.
>
>> An important aspect of Rust is the ownership-based memory management.
>>
>> The problem is, the "garbage collection is bad" era is /long/ behind us.
>>
>> Scoped ownership is a half-baked solution to the object lifetime
>> problem, that gets in the way of the programmer and isn't appropriate
>> for the vast majority of software tasks.
>>
>> Embedded systems often need custom memory management, not something that
>> the language imposes. C has malloc, yet even that gets disused in favor
>> of something else.
>>
>
> For safe embedded systems, you don't want memory management at all.
> Avoiding dynamic memory is an important aspect of safety-critical
> embedded development.
>

You still have to think about memory management even if you avoid any
dynamic memory? How are you going to mange this memory wrt your various
data structures needs....

On 3/3/2024 12:10 PM, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>
>> It is not languages like C and C++ that are "unsafe".
>
> Some empirical evidence from Google
> <https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
> shows a reduction in memory-safety errors in switching from C/C++ to Rust.

Sure. Putting corks on the forks reduces the chance of eye injuries.
Fwiw, a YouTube link to a scene in the movie Dirty Rotten Scoundrels:
Funny to me:

https://youtu.be/eF8QAeQm3ZM?t=332

Putting the cork on the fork is akin to saying nobody should be using C
and/or C++ in this "modern" age? :^)

Lawrence D'Oliveiro wrote:

> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> Nowadays, POSIX (and *nix generally) is undergoing a resurgence
>>> because of Linux and Open Source. Developers are discovering that the
>>> Linux ecosystem offers a much more productive development environment
>>> for a code-sharing, code-reusing, Web-centric world than anything
>>> Microsoft can offer.
>>
>> I do not want to live in a web-centric world.
>
> You already do.

That does not change the veracity of my statement.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Every time!

Frankly, i think we should all be programming in macros over assembly
anyway.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
You have a disease!

On 3/3/2024 2:14 PM, Blue-Maned_Hawk wrote:
> Frankly, i think we should all be programming in macros over assembly
> anyway.
>
>
>

lol! :^D

On Sun, 3 Mar 2024 22:11:14 -0000 (UTC), Blue-Maned_Hawk wrote:

> Lawrence D'Oliveiro wrote:
>
>> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> I do not want to live in a web-centric world.
>>
>> You already do.
>
> That does not change the veracity of my statement.

That doesn’t change the veracity of mine.

On Sun, 3 Mar 2024 14:06:31 -0800, Chris M. Thomasson wrote:

> On 3/3/2024 12:10 PM, Lawrence D'Oliveiro wrote:
>
>> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>>
>>> It is not languages like C and C++ that are "unsafe".
>>
>> Some empirical evidence from Google
>> <https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
>> shows a reduction in memory-safety errors in switching from C/C++ to
>> Rust.
>
> Sure. Putting corks on the forks reduces the chance of eye injuries.

Except this is Google, and they’re doing it in real-world production
code, namely Android. And showing some positive benefits from doing
so, without impairing the functionality of Android in any way.

Not like “putting corks on the forks”, whatever that might be about
....