[email protected] (Dan Cross) writes:

[Note: Followup-To: set to news.groups.proposals]

I'd like to open informal discussion around possibly creating a
new newsgroup, comp.lang.rust, for discussion of the Rust
programming language (https://rust-lang.org/). Rust is a
compiled, type- and memory- safe language that has been in open
development since 2010, and is rapidly gaining adoption in
industry and research. It often comes up in discussions related
to C and C++, but no existing group is dedicated to it.

Thoughts?

I am in favor of creating comp.lang.rust, and hereby
officially give Dan Cross my proxy in any voting.

If comp.lang.rust is created, I expect I will at least
try reading it for a while. I have had a longstanding
interest in learning rust, and have been frustated by
how horrible the existing explanatory materials are.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/03/2025 14:14, Tim Rentsch wrote:

[email protected] (Dan Cross) writes:

[Note: Followup-To: set to news.groups.proposals]

I'd like to open informal discussion around possibly creating a
new newsgroup, comp.lang.rust, for discussion of the Rust
programming language (https://rust-lang.org/). Rust is a
compiled, type- and memory- safe language that has been in open
development since 2010, and is rapidly gaining adoption in
industry and research. It often comes up in discussions related
to C and C++, but no existing group is dedicated to it.

Thoughts?

I am in favor of creating comp.lang.rust, and hereby
officially give Dan Cross my proxy in any voting.

If comp.lang.rust is created, I expect I will at least
try reading it for a while. I have had a longstanding
interest in learning rust, and have been frustated by
how horrible the existing explanatory materials are.

There is an alt.comp.lang.rust - but it has very little traffic - comp.lang.rust would be better.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/10/25 12:42 PM, Richard Harnden wrote:

On 10/03/2025 14:14, Tim Rentsch wrote:

[email protected] (Dan Cross) writes:

[Note:  Followup-To: set to news.groups.proposals]

I'd like to open informal discussion around possibly creating a
new newsgroup, comp.lang.rust, for discussion of the Rust
programming language (https://rust-lang.org/).  Rust is a
compiled, type- and memory- safe language that has been in open
development since 2010, and is rapidly gaining adoption in
industry and research.  It often comes up in discussions related
to C and C++, but no existing group is dedicated to it.

Thoughts?

I am in favor of creating comp.lang.rust, and hereby
officially give Dan Cross my proxy in any voting.

If comp.lang.rust is created, I expect I will at least
try reading it for a while.  I have had a longstanding
interest in learning rust, and have been frustated by
how horrible the existing explanatory materials are.

There is an alt.comp.lang.rust - but it has very little traffic - comp.lang.rust would be better.

There is nothing WRONG with Rust. You can build
big/complex programs using it.

However it STILL stinks of Yet Another 'C' Replacement.
Same capability, but with much more annoying syntax.

CLUE guys - make it EASIER, not WEIRDER.

Rust DOES enforce some 'safety' stuff - but if you're
a half-assed 'C' programmer you already DO all that.

Don't do all that much 'C' anymore since I retired,
mostly Python. It's easier, clearer. However a few
things - esp client/server - are still easier and
clearer in 'C'.

Keep WANTING to learn 'D' ... always install it ...
but never seem to get around ............

Five or ten years, humans won't really "program" much
anymore - it'll all be "AI". Sucky. Worrisome.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/07/2025 13:37, Dan Cross wrote:

50 years of empirical evidence has shown that, sadly, this is
just not true. Even our best and brightest C programmers still
regularly make mistakes that simply impossible to represent in
Rust, along with other languages.

Conversely, that are things that cannot be represented in (e.g.)
Rust, plus the bugs are still potentially there, just now in the
Rust compiler and runtime itself...

IOW, the idea that programmers in general need to be baby-seated
instead of given control I find not just self-defeating but really
fallacious.

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
c186282 <[email protected]> wrote:

On 3/10/25 12:42 PM, Richard Harnden wrote:

On 10/03/2025 14:14, Tim Rentsch wrote:

[email protected] (Dan Cross) writes:

[Note:  Followup-To: set to news.groups.proposals]

I'd like to open informal discussion around possibly creating a
new newsgroup, comp.lang.rust, for discussion of the Rust
programming language (https://rust-lang.org/).  Rust is a
compiled, type- and memory- safe language that has been in open
development since 2010, and is rapidly gaining adoption in
industry and research.  It often comes up in discussions related
to C and C++, but no existing group is dedicated to it.

Thoughts?

I am in favor of creating comp.lang.rust, and hereby
officially give Dan Cross my proxy in any voting.

If comp.lang.rust is created, I expect I will at least
try reading it for a while.  I have had a longstanding
interest in learning rust, and have been frustated by
how horrible the existing explanatory materials are.

There is an alt.comp.lang.rust - but it has very little traffic -
comp.lang.rust would be better.

I need to get off my bum and follow up here. The response
showed sufficient interest to warrant moving further in the
process, I've just had very little time to do so.

There is nothing WRONG with Rust. You can build
big/complex programs using it.

However it STILL stinks of Yet Another 'C' Replacement.
Same capability, but with much more annoying syntax.

CLUE guys - make it EASIER, not WEIRDER.

Rust DOES enforce some 'safety' stuff - but if you're
a half-assed 'C' programmer you already DO all that.

50 years of empirical evidence has shown that, sadly, this is
just not true. Even our best and brightest C programmers still
regularly make mistakes that simply impossible to represent in
Rust, along with other languages.

There's a reason that new languages keep appearing to address
these issues, and it's not just hubris on the part of the
designers, or a desire to be different for the sake of being
different.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1067o6p$24rjd$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 28/07/2025 13:37, Dan Cross wrote:

50 years of empirical evidence has shown that, sadly, this is
just not true. Even our best and brightest C programmers still
regularly make mistakes that simply impossible to represent in
Rust, along with other languages.

Conversely, that are things that cannot be represented in (e.g.)
Rust,

I'm not sure what this means. It is true that valid Rust
programs are not allowed to violate it's rules about, say,
memory aliasing, which means that some kinds of data structures
are difficult (or impossible) to represent using references (for
instance, circular lists using intrusive pointers). But that
doesn't mean that those programs, or programs that are
substantially equivalent, cannot be written.

For the circular list example, one could use raw pointers, and
Rust will be perfectly happy with this: the tradeoff is that the
onus shifts to the programmer to ensure that the program doesn't
violate the language's rules. But that's really no different
than the C case.

But more often than not, it turns out that using a different
data structure may actually be better anyway. A lot of people
who look at Rust and dismiss it because it's difficult to
implement something like an intrusive doubly linked list are
just trying to do that because that's the data structure they
are most familiar with, and not really considering whether it's
a good fit for the problem at hand or not. It may be that Rust
already gives you something that solves the problem, and may be
more efficient to boot.

plus the bugs are still potentially there, just now in the
Rust compiler and runtime itself...

Rust doesn't really have a runtime, per se. You give it a stack
and jump to an entry point, and you're pretty much done; sure,
there's a standard library, but that's different than (say) a
managed language with a garbage collector etc.

IOW, the idea that programmers in general need to be baby-seated

I wouldn't phrase it as "babysitting". Rather, it's
professionals making conscious choices about their tools to most
effectively do their jobs.

instead of given control I find not just self-defeating but really >fallacious.

In what way do you feel you have less control (and over what?)
in Rust than in, say, C?

I find this line of reasoning both odd, and based on a logical
fallacy unsupported by empirical evidence: specifically, it is
not the case that just because something _can_ happen, that it
_will_ happen, let alone at the same rate as other things that
are known to happen regularly.

Yes, there is always the possibility that bugs exist in a
compiler or library. But a) those tend to be rare compared to
bugs introduced by programmers in any given system, and b) the
toolset and library for a language is a much smaller surface
area than the aggregate of all programs that use that toolset
and library. That is, taken together, there is much, much more
source code written in a language out in the world than there is
in a compiler and library for that language. Also, because the
compiler and standard library for a language are used so
heavily, bugs in them tend to be noticed and addressed quickly.

But beyond that, if the position you have presented is true,
there should be data that supports it, and there's not. Rust
has been used in production systems now for about 10 years;
there's plenty of code out there written in it, in a bunch of
different domains from embedded firmware to web services and
user applications, and the available data suggests that it _is_
a win in those domains; not just in safety or reduced defect
rates, but even in performance of generated code and
productivity. For example, here's a presentation from Google
engineering director Lars Bergstrom about it: https://www.youtube.com/watch?v=QrrH2lcl9ew
And here's post from the Android security team about memory
safety that talks about wins from Rust: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things _do_ in fact save lives.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/07/2025 17:16, Dan Cross wrote:

In article <1067o6p$24rjd$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 28/07/2025 13:37, Dan Cross wrote:

<snip>

IOW, the idea that programmers in general need to be baby-seated

I wouldn't phrase it as "babysitting". Rather, it's
professionals making conscious choices about their tools to most
effectively do their jobs.

instead of given control I find not just self-defeating but really
fallacious.

In what way do you feel you have less control (and over what?)
in Rust than in, say, C?

To be clear, I have nothing against the institution of a
comp.lang.rust (on the contrary, I'd be tempted to say), nor
against the Rust language itself: I am rather commenting on
some questions of principle, and maybe some marketing slogans,
especially on the themes of "safety" on a side and "assisted"
programming on the other.

Indeed, I am not against a stratification of languages from lower
to higher level either, actually that's quite needed, I am just
of the idea that programmers should not be "protected" by anybody
but more competent programmers: but of course with that goes a
quite different idea of what *software development* means, and
to me it does not primarily mean we buy "solutions" at the shop,
the very opposite of that.

Instead we get an inversion of the chain of control and of
responsibility that is rather one of the key ingredients, the
other being the denial of the very state of the art, of the
disaster that the whole industry has been made into across
the last ~30 years...

...and the self-fulfilling prophecies, since average is the data,
averaging are and have been the policies, average are the results,
and the circle is closed: with the triumph of the levelling down
to ineptitude and consumeristic dependence.

Here is rather an analogy: go tell a race car driver that it is
"unsafe" for them to touch their breaks in a turn, and that you
actually have a "solution" in mind that will automatically disable
the breaks in a turn (and punish the driver for it)... or something
along that line.

Here is not an analogy: only a competent programmer knows the
discipline, the principles, the practices, and in fact how to
organise not only a production unit that delivers excellent
products, but also that continually grows in the level of
competence and professionalism, with clear paths for learning
and action since the beginner stages.

Because software engineering is the most complex engineering
that there is: it takes some 10 years to those who are really
committed to start understanding what it is actually about,
and some another 10 years of at least as much commitment to
become real pros.

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <10686pv$24rjd$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 28/07/2025 17:16, Dan Cross wrote:

In article <1067o6p$24rjd$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 28/07/2025 13:37, Dan Cross wrote:

<snip>

IOW, the idea that programmers in general need to be baby-seated

I wouldn't phrase it as "babysitting". Rather, it's
professionals making conscious choices about their tools to most
effectively do their jobs.

instead of given control I find not just self-defeating but really
fallacious.

In what way do you feel you have less control (and over what?)
in Rust than in, say, C?

To be clear, I have nothing against the institution of a
comp.lang.rust (on the contrary, I'd be tempted to say), nor
against the Rust language itself:

Sure, that's fair. This is separate.

I am rather commenting on
some questions of principle, and maybe some marketing slogans,
especially on the themes of "safety" on a side and "assisted"
programming on the other.

I'm not terribly interested in marketing slogans, to be honest.

"Safety" in this case has a very well-defined meaning, which may
not be the same as yours. As for "assisted", I'm not sure what
that's about. Perhaps you mean the way that the language
assists a programmer in writing more robust software? How is
that any different than C assisting a programmer to write more
robust software than straight assembly? Or assembly assisting
to write more robust software than programming directly in
machine code?

Indeed, I am not against a stratification of languages from lower
to higher level either, actually that's quite needed, I am just
of the idea that programmers should not be "protected" by anybody
but more competent programmers: but of course with that goes a
quite different idea of what *software development* means, and
to me it does not primarily mean we buy "solutions" at the shop,
the very opposite of that.

The competence argument is ancient: as I alluded to above, when
assemblers began to replace direct machine-language coding
(often in octal!), being both less error prone and more
expressive, they were decried as hopelessly inefficient (read:
wasteful of very expensive computer time!) and their users
simply lacking in some abstract definition of skill. When
high-level languages began to emerge 70-ish years ago, and
people noted that defect rates went down when programming them
relative to assembler, many macro assembly language programmers
made similar arguments, perhaps having forgotten that they
themselves had been the object of that same criticism only a few
short years before.

Bluntly, the argument has never really held up in the face of
actual evidence. The best C programmers in the world have
written code with memory safety bugs: I've personally seen such
bugs in programs written by the man who designed the language
and implemented its first compilers. I've seen similar things
from folks on the language standards committee. In other cases,
programs have _appeared_ to work flawlessly for decades until a
new point release of a compiler came out, and it turned out the
program actually exhibited some kind of undefined behavior that
the new compiler used to justify changing some crucial behavior
in an unexpected way and the program "broke."

If the best programmers in the world make these mistakes, then
it's not a competence or skill issue.

Instead we get an inversion of the chain of control and of
responsibility that is rather one of the key ingredients, the
other being the denial of the very state of the art, of the
disaster that the whole industry has been made into across
the last ~30 years...

...and the self-fulfilling prophecies, since average is the data,
averaging are and have been the policies, average are the results,
and the circle is closed: with the triumph of the levelling down
to ineptitude and consumeristic dependence.

I started programming professionally about 30 years ago, and at
the time, people were making the exact same arguments, about how
the industry had been ruined over the previous 30 years, that we
were spoiled by bitmapped graphics (what was wrong with a 80x24
VT-series terminal? Or even a teletype?), cheap RAM, cheaper
disk, and ever-increasing CPU speeds, and how much we had lost
by moving away from systems written by truly competent
programmers in assembler, to high(er)-level languages that let
you get away with not really understanding the machine, being
inefficient, and that inevitably led to "toys" like Unix because
people no longer had the discipline required to have any sort of
idea what they were _actually_ doing.

This was always a non-sequitor. The industry may be a disaster
(I agree with that), but that doesn't mean that choosing to use
a tool has better memory safety properties is a cause or symptom
of that.

Interestingly, with Rust, the language famously has a very steep
learning curve (a former colleague once called it, "near
vertical"), and is not known as a language for amateurs, so
would seem to be a counter example against the kind of
mediocrity you described.

Similarly, one could make a strong case that arguing against
memory safe langauges is a denial of the state of the art,
which has largely moved on from e.g. C, C++, Java, COBOL, PL/I,
RPG-2, Macro assemblers, and so on. Even Fortran is no longer
really the state of the art for numerical programming.

Here is rather an analogy: go tell a race car driver that it is
"unsafe" for them to touch their breaks in a turn, and that you
actually have a "solution" in mind that will automatically disable
the breaks in a turn (and punish the driver for it)... or something
along that line.

That's a bad analogy. A better one is the race car driver
telling you that they don't need a 5-point restraint harness or
flash-resistent outer suit because they already know how to
drive and won't get into a wreck, and that those things are only
for less competent drivers. And yet, just like we've seen the
best programmers in the world introduce bugs in e.g. C code, we
have seen the best racers in the world get into horrific
crashes.

The guy who tells you he doesn't need that stuff is going to end
up dead in a crash that another, I would argue more competent,
driver can walk away from precisely because competence means
that the latter understands the value of and uses that kind of
safety equipment correctly, without cutting corners.

Here is not an analogy: only a competent programmer knows the
discipline, the principles, the practices, and in fact how to
organise not only a production unit that delivers excellent
products, but also that continually grows in the level of
competence and professionalism, with clear paths for learning
and action since the beginner stages.

Those programmers also understand the value of defense in depth,
and of chosing tools that optimize their ability to deliver
value in the form of performant and correct programs, produced
in a reasonable amount of time. Such programmers devote
considerable time to professional development, learning and
adopting new practices and tools when that makes sense, and
shedding older practices and tools when that makes sense.

A mark of professionalism is understanding the tradeoffs
involved and making wise choices. The field is not stagnant,
and while it may suck generally, that does not mean that that
chosing to use a safer tool is an admission of incompetence.

There was a generation of programmers who produced application
software in macro assembler langauges on machines from the IBM
System/360 to the DEC VAX to the Data General Nova. Hands down,
the _best_ programmer I've ever met in my life's favorite
language was PDP-10 assembly. But there's a reason we don't
write new systems in assembler anymore, and it's not a skill or
competence issue: it's because we get better software from
higher-level tools.

Because software engineering is the most complex engineering
that there is: it takes some 10 years to those who are really
committed to start understanding what it is actually about,
and some another 10 years of at least as much commitment to
become real pros.

I'd say that's more a reflection on the overall immaturity of
the field. Human beings have been building bridges over rivers
for thousands of years; it wasn't until the 19th century that
we started to actually get good at it. We've been programming
computers for less than 100, and we're still at the "chop down a
tree so it falls over the narrow part" stage. We also hold
ourselves back because, when someone comes up and says, "hey,
have you heard about this reinforced concrete thing? It's more
durable and can support a lot more weight..." our response is
too often, "what's wong with wood? If you were more efficient
you wouldn't _need_ to support all that weight."

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement with
the material points under discussion are not persuasive. If you
disagree with any of my statements, you can engage with the
arguments in good faith and provide data.

Or, if you prefer, how about a comparative study of a decently
large program, one version written in C, and the other in Rust?
Compare: https://github.com/dancrossnyc/rxv64 and https://github.com/mit-pdos/xv6-public

Otherwise, I suggest that you buckle up when you get behind the
wheel.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/07/2025 16:16, Dan Cross wrote:

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things_do_ in fact save lives.

Whilst you are unlikely ever to catch me within a light year of
Rust, I do agree with your substantive point - that amagicality
is not a good reason to reject a programming technology.

I must, however, take issue with your word 'all' in your last
sentence. To invalidate it only takes one death caused by a
seatbelt that prevents a wearer from escaping a fatal crash (eg
burning or drowning).

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1069ltn$2ffpl$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 28/07/2025 16:16, Dan Cross wrote:

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things _do_ in fact save lives.

Whilst you are unlikely ever to catch me within a light year of
Rust, I do agree with your substantive point - that amagicality
is not a good reason to reject a programming technology.

Agreed.

I must, however, take issue with your word 'all' in your last
sentence. To invalidate it only takes one death caused by a
seatbelt that prevents a wearer from escaping a fatal crash (eg
burning or drowning).

I can see why you might interpret it that way, but I'm not sure
your conclusion actually follows from my statement. "All data
shows that those things _do_ in fact save lives" doesn't imply
that no lives are lost, even when restraint harnesses, flash
suits, and so on are used. Nor does it imply that no one ever
died because, say, the restraint harness resulted in suspension
trauma or something. Rather, taken in context, it simply means
that when used, more lives are saved relative to when not used.
"It always rains on Tuesday" doesn't say anything at all about
whether it rains on Wednesday or not.

Regardless, clearly there is some ambiguity here, so a tighter
statement is warranted. How about, "available data shows that
with proper use of restraint harnesses and flash suits, drivers
survive more crashes than when those things are not used." ?

Similarly, available data shows that programs written in the
safe subset of Rust have significantly lower memory-related
defect rates than those same programs written in C.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement with
the material points under discussion are not persuasive. If you
disagree with any of my statements, you can engage with the
arguments in good faith and provide data.

Or, if you prefer, how about a comparative study of a decently
large program, one version written in C, and the other in Rust?
Compare: https://github.com/dancrossnyc/rxv64 and https://github.com/mit-pdos/xv6-public

Otherwise, I suggest that you buckle up when you get behind the
wheel.

I personally don't know enough Rust to make any reasonable comparison
with other languages. I also think there is scope for all sorts of
languages, and it seems perfectly reasonable to me for Rust to be
"better" than C while also having C be "better" than Rust - different
languages have their strengths and weaknesses.

But one thing that bothers me is that Rust advocates almost invariably
compare modern Rust, programmed by top-rank programmers interested in
writing top-quality code, with ancient C written by people who may have
very different abilities and motivations.

Rust is the new, cool language - the programmers who use it are
enthusiasts who are actively interested in programming, and talented
enough to learn the language themselves and are keen to make the best of
it. C, on the other hand, has been the staple language for workhorse
tasks. The great majority of people programming in C over the decades
do so because that's what they learned at university, and that's what
their employers' pay them to write. They write C code to earn a living,
and while I am sure most take pride in their jobs, their task is not to
write top-quality bug-free C code, but to balance the cost of writing
code that is good enough with the costs and benefits to customers.

So it is an artificial and unfair comparison to suggest, as many Rust enthusiasts do, that existing C code has lots of bugs that could be
prevented by writing the code in Rust - the bugs could be prevented
equally well by one of those Rust programmers re-writing the code in
good, modern C using modern C development tools.

I also see little in the way of comparisons between Rust and modern C++.
Many of the "typical C" bugs - dynamic memory leaks and bugs, buffer overflows in arrays and string handling, etc., - disappear entirely when
you use C++ with smart pointers, std::vector<>, std::string<>, and the
C++ Core Guidelines. (Again - I am not saying that C++ is "better" than
Rust, or vice versa. Each language has its pros and cons.)


So while I appreciate that comparing these two projects might be more
useful than many vague "C vs. Rust" comparisons, it is still a
comparison between a 10-20 year old C project and a modern Rust design.
The most immediate first-impression difference between the projects is
that the Rust version is sensibly organised in directories, while the C
project jumbles OS code and user-land utilities together. That has,
obviously, absolutely nothing to do with the languages involved. Like
so often when a Rust re-implementation of existing C code gives nicer,
safer, and more efficient results, the prime reason is that you have a re-design of the project in a modern style using modern tools with the experience of knowing the existing C code and its specifications (which
have usually changed greatly during the lifetime of the C code). You'd
get at least 90% of the benefits by doing the same re-write in modern C.


(As for the topic of this thread - Rust is getting steadily more popular regardless of what anyone may think about the language, so it's own
newsgroup seems perfectly reasonable to me.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 17:37, David Brown wrote:

But one thing that bothers me is that Rust advocates almost invariably compare modern Rust, programmed by top-rank programmers interested in
writing top-quality code, with ancient C written by people who may have
very different abilities and motivations.

Which is another piece of the same propaganda and self-fulfilling
prophecies: rather, once upon a time we knew way *better*, and
still do, as we have also never stopped learning and improving.

Not trying to detracting from anybody's work in particular, but
the mainstream myths, the rationale and the methods even before
any techniques, are upside-down to put it charitably.

Indeed, not to even mention any respect for competence and
experience, with all that that implies in terms of growing
and learning, now especially good luck with that "safety"...

Anyway, enough of that. (EOD.)

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 18:24, Julio Di Egidio wrote:

On 29/07/2025 17:37, David Brown wrote:

But one thing that bothers me is that Rust advocates almost invariably
compare modern Rust, programmed by top-rank programmers interested in
writing top-quality code, with ancient C written by people who may
have very different abilities and motivations.

Which is another piece of the same propaganda and self-fulfilling
prophecies: rather, once upon a time we knew way *better*, and
still do, as we have also never stopped learning and improving.

Not trying to detracting from anybody's work in particular, but
the mainstream myths, the rationale and the methods even before
any techniques, are upside-down to put it charitably.

Indeed, not to even mention any respect for competence and
experience, with all that that implies in terms of growing
and learning, now especially good luck with that "safety"...

The whole thing is completely misguided: e.g. I have been
writing device drivers for few years in C with zero bugs,
some of which are still in operation today; or, I have
written apps in VBA, because only that could do... etc.

Meaning, I/we can use *any* language (platform) that at least
does as advertised, and still get the job done and done well:
indeed which language I/we end up using is merely a matter of
(availability and) *convenience* and nothing more than that.

And so on up to again the global economic, social, and
cultural scenario, of which the sorry state of an entire
and so critical industry is but an instrumental part.

Anyway, enough of that.  (EOD.)

I wish. ;)

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 13:27, Dan Cross wrote:

In article <1069ltn$2ffpl$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 28/07/2025 16:16, Dan Cross wrote:

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things _do_ in fact save lives.

Whilst you are unlikely ever to catch me within a light year of
Rust, I do agree with your substantive point - that amagicality
is not a good reason to reject a programming technology.

Agreed.

I must, however, take issue with your word 'all' in your last
sentence. To invalidate it only takes one death caused by a
seatbelt that prevents a wearer from escaping a fatal crash (eg
burning or drowning).

I can see why you might interpret it that way, but I'm not sure
your conclusion actually follows from my statement. "All data
shows that those things _do_ in fact save lives" doesn't imply
that no lives are lost, even when restraint harnesses, flash
suits, and so on are used.

Well, yes it does. "All data shows X" most definitely implies
that "no data shows not-X".

But I've made my point, so on that note I will underline my
acknowledgement that I'm being ++picky.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106cf06$32d5u$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 29/07/2025 13:27, Dan Cross wrote:

In article <1069ltn$2ffpl$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 28/07/2025 16:16, Dan Cross wrote:

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things _do_ in fact save lives.

Whilst you are unlikely ever to catch me within a light year of
Rust, I do agree with your substantive point - that amagicality
is not a good reason to reject a programming technology.

Agreed.

I must, however, take issue with your word 'all' in your last
sentence. To invalidate it only takes one death caused by a
seatbelt that prevents a wearer from escaping a fatal crash (eg
burning or drowning).

I can see why you might interpret it that way, but I'm not sure
your conclusion actually follows from my statement. "All data
shows that those things _do_ in fact save lives" doesn't imply
that no lives are lost, even when restraint harnesses, flash
suits, and so on are used.

Well, yes it does. "All data shows X" most definitely implies
that "no data shows not-X".

That is true, but irrelevant: the issue here is the definition
of "X". "[T]hose things _do_ in fact save lives" is not the
same as "all lives are saved, and none are lost due to the
equipment." I never said the latter, and it is not implied by
the former statement. Conflating them is a logical error, but I
did acknowledge that the statement can reasonably be seen as
sufficiently imprecise that it should be revised, and did so.

But I've made my point, so on that note I will underline my
acknowledgement that I'm being ++picky.

I fear I am, as well.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/07/2025 12:30, Dan Cross wrote:

In article <106cf06$32d5u$[email protected]>,
Richard Heathfield <[email protected]> wrote:

<snip>

But I've made my point, so on that note I will underline my
acknowledgement that I'm being ++picky.

I fear I am, as well.

And thus it is that two complete strangers have a blazing row in
public, not a single punch is thrown or expletive uttered, and
they end with a smile and a handshake.

Gotta love Usenet.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves... Meanwhile real production is in the
hands of the marketing and project management guys, while
at writing code you want the computer scientists, in that
proving that you not haven't got the faintest idea what
software even means, but also you haven't got a clue
where your own discipline starts and where it ends!

Indeed, I was a top notch consultant in my area and giving
university lessons on technology and technologies up to the
'90, i.e. before SE or CS even existed as faculties. Then
the fucking locusts descended on us, and the fucking frauds
all just to happy to jump on yet another bandwagon...

Sure, do open a comp.lang.rust, you have no fucking
clue what "picky" even means.

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106dji3$3aqcv$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

Wow. You seem nice.

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves...

Actually, I was suggesting that _you_ provide some data.

Meanwhile real production is in the
hands of the marketing and project management guys, while
at writing code you want the computer scientists, in that
proving that you not haven't got the faintest idea what
software even means, but also you haven't got a clue
where your own discipline starts and where it ends!

You haven't shown any code. You haven't made any technical
arguments. You haven't shown any data. You've just thrown out
insults and made a bunch of vague assertions about...something;
none of it really makes a lot of sense.

Anyway, ad hominem attacks are not persuasive, either.

Indeed, I was a top notch consultant in my area and giving
university lessons on technology and technologies up to the
'90, i.e. before SE or CS even existed as faculties. Then
the fucking locusts descended on us, and the fucking frauds
all just to happy to jump on yet another bandwagon...

Sure, do open a comp.lang.rust, you have no fucking
clue what "picky" even means.

*shrug* Ok, dude. Whatever you say. 8-/

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106df2q$39nv6$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 30/07/2025 12:30, Dan Cross wrote:

In article <106cf06$32d5u$[email protected]>,
Richard Heathfield <[email protected]> wrote:

<snip>

But I've made my point, so on that note I will underline my
acknowledgement that I'm being ++picky.

I fear I am, as well.

And thus it is that two complete strangers have a blazing row in
public, not a single punch is thrown or expletive uttered, and
they end with a smile and a handshake.

The state of violent agreement! :-)

Gotta love Usenet.

I do miss the collegial atmosphere of older USENET.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/07/2025 20:00, Dan Cross wrote:

In article <106dji3$3aqcv$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

Wow. You seem nice.

"Nice"?? Have you looked outside your window lately?

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves...

Actually, I was suggesting that _you_ provide some data.

As I did say since earlier, that very *paradigm* is a global
fraud! It's not my fault if you at best keep missing the point.

Indeed, do you think *you* are "nice"? For your records, I have
offended nobody, except maybe the incivilization and inculture
that we/you collectively are.

Sure, keep going...

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106dok3$3b9ks$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 30/07/2025 20:00, Dan Cross wrote:

In article <106dji3$3aqcv$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

Wow. You seem nice.

"Nice"?? Have you looked outside your window lately?

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves...

Actually, I was suggesting that _you_ provide some data.

As I did say since earlier, that very *paradigm* is a global
fraud! It's not my fault if you at best keep missing the point.

That's ridiculous.

Indeed, do you think *you* are "nice"? For your records, I have
offended nobody, except maybe the incivilization and inculture
that we/you collectively are.

You accused me of being unable to read. That's rude, and
offensive. If you don't understand that, it's really not my
problem.

Sure, keep going...

No.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106dpis$3b9ks$[email protected]>,
Julio Di Egidio <[email protected]> wrote:

On 30/07/2025 20:40, Dan Cross wrote:

You accused me of being unable to read. That's rude,

No, that was a *retort*, but you are either too stupid or
too dishonest to just shut the fuck up, let alone apologise.

Apologize for...what?

*Plonk*

Good.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/07/2025 20:40, Dan Cross wrote:

You accused me of being unable to read. That's rude,

No, that was a *retort*, but you are either too stupid or
too dishonest to just shut the fuck up, let alone apologise.

*Plonk*

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/07/2025 13:30, Dan Cross wrote:

In article <106cf06$32d5u$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 29/07/2025 13:27, Dan Cross wrote:

In article <1069ltn$2ffpl$[email protected]>,
Richard Heathfield <[email protected]> wrote:

On 28/07/2025 16:16, Dan Cross wrote:

Does this mean that the language is perfect, and will prevent
all bugs? No, of course not; it's not magic. But this line of
reasoning that says, "well, you can still have bugs, so what's
the point?" inevitably ignores the relative rate of those bugs
between languages, which does matter. It's the same argument
that says, "you can still die in a car crash, so we don't need
seatbelts or airbags." Yet all available data shows that those
things _do_ in fact save lives.

Whilst you are unlikely ever to catch me within a light year of
Rust, I do agree with your substantive point - that amagicality
is not a good reason to reject a programming technology.

Agreed.

I must, however, take issue with your word 'all' in your last
sentence. To invalidate it only takes one death caused by a
seatbelt that prevents a wearer from escaping a fatal crash (eg
burning or drowning).

I can see why you might interpret it that way, but I'm not sure
your conclusion actually follows from my statement. "All data
shows that those things _do_ in fact save lives" doesn't imply
that no lives are lost, even when restraint harnesses, flash
suits, and so on are used.

Well, yes it does. "All data shows X" most definitely implies
that "no data shows not-X".

That is true, but irrelevant: the issue here is the definition
of "X". "[T]hose things _do_ in fact save lives" is not the
same as "all lives are saved, and none are lost due to the
equipment." I never said the latter, and it is not implied by
the former statement. Conflating them is a logical error, but I
did acknowledge that the statement can reasonably be seen as
sufficiently imprecise that it should be revised, and did so.

Without taking any sides here, it is easy to make the mistake of
thinking that logical rules can apply to sets of propositions in the
same way as they apply to propositions. This leads to the famous Cheese Sandwich Theorem:

1. Nothing is better than complete happiness.
2. A cheese sandwich is better than nothing.
3. Therefore, a cheese sandwich is better than complete happiness.

Time for lunch :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/07/2025 19:08, Julio Di Egidio wrote:

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio  <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves... Meanwhile real production is in the
hands of the marketing and project management guys, while
at writing code you want the computer scientists, in that
proving that you not [only] haven't got the faintest idea
what software even means, but also you haven't got a clue
where your own discipline starts and where it ends!

On the "software crisis":
<< [...] just there is an essential distinction to make, between
proper and improper software production, with the vast majority of
the software endeavours nowadays belonging to the latter category.
Then, and just to begin with, the very shape of the industry-specific performance surveys would change... In fact, I would claim that proper
software developers (and, scaling up, proper software production units)
do, already today, consistently provide near to optimal results, all environmental circumstances considered! >> <https://architectando.blogspot.com/2012/11/on-software-crisis.html>

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <106lf4d$15pv5$[email protected]>,
David Brown <[email protected]> wrote:

On 30/07/2025 13:30, Dan Cross wrote:

In article <106cf06$32d5u$[email protected]>,
Richard Heathfield <[email protected]> wrote:
[snip]

Without taking any sides here, it is easy to make the mistake of
thinking that logical rules can apply to sets of propositions in the
same way as they apply to propositions. This leads to the famous Cheese >Sandwich Theorem:

1. Nothing is better than complete happiness.
2. A cheese sandwich is better than nothing.
3. Therefore, a cheese sandwich is better than complete happiness.

Time for lunch :-)

Make it pastrami on rye and you may be onto something there. :-D

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/08/2025 17:55, Julio Di Egidio wrote:

On 30/07/2025 19:08, Julio Di Egidio wrote:

On 29/07/2025 14:16, Dan Cross wrote:

In article <106a04v$2hiar$[email protected]>,
Julio Di Egidio  <[email protected]> wrote:

On 29/07/2025 00:18, Dan Cross wrote:

I'm not terribly interested in marketing slogans, to be honest.
"Safety" in this case has a very well-defined meaning, which may
not be the same as yours.

Maybe you don't realise it, but you are *only* repeating
the fake history and the fraudulent marketing slogans.

Unsupported assertions coupled with a lack of engagement

Or maybe you just can't read.

and provide data.

Sure, biased data for worse than wrong models that only
confirm themselves... Meanwhile real production is in the
hands of the marketing and project management guys, while
at writing code you want the computer scientists, in that
proving that you not [only] haven't got the faintest idea
what software even means, but also you haven't got a clue
where your own discipline starts and where it ends!

On the "software crisis":
<< [...] just there is an essential distinction to make, between
proper and improper software production, with the vast majority of
the software endeavours nowadays belonging to the latter category.
Then, and just to begin with, the very shape of the industry-specific performance surveys would change... In fact, I would claim that proper software developers (and, scaling up, proper software production units)
do, already today, consistently provide near to optimal results, all environmental circumstances considered! >> <https://architectando.blogspot.com/2012/11/on-software-crisis.html>

Roughly a decade later, the 95% becomes 99%:

Collective disaster:
<< [...] just the poorly thought out and written code that is
ubiquitous nowadays, in all guidance as in all practice, is
actually a cost, not just worthless: a generally unperceived
cost since that is 99% of the industry by now, indeed the very
rationale that founds and sustains it is that that is the best
we can do. >> <https://architectando.blogspot.com/2024/10/collective-disaster.html>

-Julio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)