[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?
cross@spitfire.i.gajendra.net (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.
[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/).
On 10/03/2025 14:14, Tim Rentsch wrote:
cross@spitfire.i.gajendra.net (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.
On 3/10/25 12:42 PM, Richard Harnden wrote:
On 10/03/2025 14:14, Tim Rentsch wrote:
cross@spitfire.i.gajendra.net (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.
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.
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.
In article <1067o6p$24rjd$2@dont-email.me>,<snip>
Julio Di Egidio <julio@diegidio.name> wrote:
On 28/07/2025 13:37, Dan Cross wrote:
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?
On 28/07/2025 17:16, Dan Cross wrote:
In article <1067o6p$24rjd$2@dont-email.me>,<snip>
Julio Di Egidio <julio@diegidio.name> wrote:
On 28/07/2025 13:37, Dan Cross wrote:
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.
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.
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.
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.
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).
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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.
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.
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.)
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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.)
In article <1069ltn$2ffpl$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> 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.
On 29/07/2025 13:27, Dan Cross wrote:
In article <1069ltn$2ffpl$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> 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.
In article <106cf06$32d5u$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> wrote:
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.
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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
and provide data.
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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.
On 30/07/2025 12:30, Dan Cross wrote:
In article <106cf06$32d5u$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> 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.
In article <106dji3$3aqcv$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> wrote:
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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.
On 30/07/2025 20:00, Dan Cross wrote:
In article <106dji3$3aqcv$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> wrote:
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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...
You accused me of being unable to read. That's rude,
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*
In article <106apsa$2nju3$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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.
I agree with this: modern C certainly has its place, and it
would be foolish to think that the many billions of lines of C
(or C++, for that matter) in existence today are simply going to
vanish and be replaced with well-written, idiomatic Rust
tomorrow.
But no one serious is suggesting that. What I think a number of
foks _are_ suggesting is that experience is proving that we get
better, less buggy results out of Rust than equivalent C.
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.
You have a point that transcends any sort of Rust<->C debate.
Indeed, it is difficult to compare C'23 to C'89, let alone pre-
ANSI "typesetter" C, let alone the C that, say, 6th Edition Unix
was written in. Those are all very different languages.
That said, there are some things that are simply impossible to
represent in (correct, safe) Rust that are are known to be
problematic, but that you cannot escape in C. The canonical
example in the memory-safety domain is are Rust's non-nullable
reference types vs C pointers; the latter can be nil, the former
cannot. And while Rust _does_ have "raw" pointers (that can be
null), you have to use `unsafe` to dereference them. The upshot
is that in safe rust, you cannot dereference a NULL-pointer;
perhaps Andy Hoare's "billion dollar mistake" can be fixed.
I also see little in the way of comparisons between Rust and modern C++.
Really? I see quite a lot of comparison between Rust and C++.
Most of the data out of Google and Microsoft, for instance, is
not comparing Rust and C, it's actually comparing Rust and C++.
Where Rust is compared to C most often is in the embedded space.
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.)
And yet, experience has shown that, even in very good C++ code
bases, we find that programs routinely hit those sorts of
issues. Indeed, consider trying to embed a reference into a
`std::vector`, perhaps so that one can do dynamic dispatch thru
a vtable. How do you do it? This is an area where C++
basically forces you to use a pointer; even if you try to put a
`unique_ptr` into the vector, those can still own a `nullptr`.
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.
Not really. rxv64 has a very specific history: we were working
on a new (type-1) hypervisor in Rust, and bringing new engineers
who were (usually) very good C and C++ programmers onto the
project. While generally experienced, these folks had very
little experience with kernel-level programming, and almost none
in Rust. For the OS bits, we were pointing them at MIT's course
materials for the 6.828 course, but those were in C and for
32-bit x86, so I rewrote it in Rust for x86_64.
In doing so, I took care to stay as close as I reasonably could
to the original. Obviously, some things are different (most
system calls are implemented as methods on the `Proc` type, for
example, and error handling is generally more robust; there are
some instances where the C code will panic in response to user
action because it's awkward to return an error to the calling
process, but I can bubble thus back up through the kernel and
into user space using the `Result` type), but the structure is
largely the same; my only real conceit to structural change in
an effort to embrace modernity was the pseudo-slab allocator for
pipe objects. Indeed, there are some things where I think the
rewrite is _less_ elegant than the original (the doubly-linked
list for the double-ended queue of free buffers in the block
caching layer, for instance: this was a beautiful little idea in
early Unix, but its expression in Rust -- simulated using
indices into the fixed-size buffer cache -- is awkward).
The Rust port did expose a few bugs in the original, which I
fixed and contributed back to MIT. And while it's true that the
xv6 code was initially written in the mid 00's, it is still very
much used and maintained (though MIT has moved on to a variant
that targets RISC-V and sunsetted the x86 code). Also, xv6 has
formed the basis for several research projects, and provided a
research platform that has resulted in more than one
dissertation. To say that it is not representative of modern C
does not seem accurate; it was explicitly written as a modern
replacement for 6th Edition Unix, after all. And if it is not
considered modern, then what is?
I hear this argument a lot, but it quickly turns into a "no true
Scotsman" fallacy.
This is less frivilous than many of the
other arguments that are thrown out to just dismiss Rust (or any
other technology, honestly) that often boil down to, honestly,
emotion. But if the comparison doesn't feel like it's head to
head, then propose a _good_ C code base to compare to Rust.
(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.)
Fair point. I changed the "Subject:" header to reflect the
drift.
- Dan C.
In article <106cf06$32d5u$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 29/07/2025 13:27, Dan Cross wrote:
In article <1069ltn$2ffpl$1@dont-email.me>,
Richard Heathfield <rjh@cpax.org.uk> 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.
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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 30/07/2025 19:08, Julio Di Egidio wrote:
On 29/07/2025 14:16, Dan Cross wrote:
In article <106a04v$2hiar$1@dont-email.me>,
Julio Di Egidio <julio@diegidio.name> 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>
On 29/07/2025 20:27, Dan Cross wrote:
In article <106apsa$2nju3$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 29/07/2025 14:16, Dan Cross wrote:
[snip]
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.
I agree with this: modern C certainly has its place, and it
would be foolish to think that the many billions of lines of C
(or C++, for that matter) in existence today are simply going to
vanish and be replaced with well-written, idiomatic Rust
tomorrow.
But no one serious is suggesting that. What I think a number of
foks _are_ suggesting is that experience is proving that we get
better, less buggy results out of Rust than equivalent C.
Actually, I think many people /are/ suggesting that Rust be used instead
of C as though it were a clear and complete "upgrade" and that those who >write C today should switch to Rust and magically create "safer" code
(for some value of "safer").
Now, I /do/ think that many people who write C code today could write
code that is substantially better code (fewer bugs, more efficient >development, or other metrics) if they used different languages. (I
also think the software world could benefit if some people stopped >programming altogether.) I don't see many areas for which C is the
ideal choice of language for new code.
But I don't think Rust is the magic bullet that a number of its
advocates appear to believe. I think many of those C programmers would
be better off switching to C++, Python, or various other languages (with >Rust being included as one of those).
(To be clear, I am not saying that /you/ are claiming Rust is anything
like that.)
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.
You have a point that transcends any sort of Rust<->C debate.
Indeed, it is difficult to compare C'23 to C'89, let alone pre-
ANSI "typesetter" C, let alone the C that, say, 6th Edition Unix
was written in. Those are all very different languages.
Yes, I agree with that. Languages have changed over the last few
decades, even when within the confines of just a single nominal language >(like "C", "C++", "Python", or any other living language). The way we
use languages, and what we do with them, has also changed - again, even
if you simply stick to a single language variant (such as C90). And the >tools have changed hugely too.
That said, there are some things that are simply impossible to
represent in (correct, safe) Rust that are are known to be
problematic, but that you cannot escape in C. The canonical
example in the memory-safety domain is are Rust's non-nullable
reference types vs C pointers; the latter can be nil, the former
cannot. And while Rust _does_ have "raw" pointers (that can be
null), you have to use `unsafe` to dereference them. The upshot
is that in safe rust, you cannot dereference a NULL-pointer;
perhaps Andy Hoare's "billion dollar mistake" can be fixed.
That is all true (other than Tony Hoare's name),
and it is definitely
one of Rust's many positive features. However, it is easy to exaggerate
the importance of this for many reasons:
1. As I understand it, "unsafe" Rust code is common, especially in
low-level code.
I think it is a good thing to have the separation of
"safe" and "unsafe" code, and isolating riskier coding techniques is >beneficial. But perhaps rather than dividing a Rust program into "safe"
and "unsafe" parts, it would be better still to divide the program into >low-level efficiency-critical code written in C, and write the majority
of the code in a higher level managed language where you don't really
have pointers, or at least where any bugs in pointer-style concepts
would be caught immediately. Again, I am not saying Rust's philosophy
is bad here, merely that there are alternatives that could be better and >Rust's benefits are often over-sold.
2. It is perfectly possible to write C code without having errors due to >null pointer dereferences. I do not recall ever having had a null
pointer bug in any C code I have written over the last 30+ years. I
have occasionally had other pointer-related errors, typically as a
result of typos and usually found very quickly.
These kinds of mistakes
are avoided with due care and attention to the coding, appropriate
testing, sensible coding standards, and other good development
practices. Good tools can help catch problems at compile time (such as >compiler warnings about uninitialised variables, or extensions to mark >function parameters as "non-null"). They can also catch bugs quickly at >runtime, such as using sanitisers. I am a big fan of any language
feature that can make it more difficult to put bugs in your code (the
power of a programming languages mainly comes not from what it allows
you to write, but what it stops you from writing). But things like null >pointer bugs are not a symptom of C programming, but of poor software >development - and that is language independent.
3. Alternative existing and established languages already provide
features that handle this - the prime example being C++.
I also see little in the way of comparisons between Rust and modern C++.
Really? I see quite a lot of comparison between Rust and C++.
Most of the data out of Google and Microsoft, for instance, is
not comparing Rust and C, it's actually comparing Rust and C++.
Where Rust is compared to C most often is in the embedded space.
I work with embedded development, so maybe that colours my reading!
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.)
And yet, experience has shown that, even in very good C++ code
bases, we find that programs routinely hit those sorts of
issues. Indeed, consider trying to embed a reference into a
`std::vector`, perhaps so that one can do dynamic dispatch thru
a vtable. How do you do it? This is an area where C++
basically forces you to use a pointer; even if you try to put a
`unique_ptr` into the vector, those can still own a `nullptr`.
Sure, there are still occasions when you need raw pointers in C++. It
is far from a "perfect" language, and suffers greatly from many of its
good ideas being add-ons rather than in the original base language,
meaning the older more "dangerous" styles being still available (and
indeed often the default). But just as you should not need raw pointers
in most of your Rust programming, you should not need raw pointers in
most of your C++ programming.
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.
Not really. rxv64 has a very specific history: we were working
on a new (type-1) hypervisor in Rust, and bringing new engineers
who were (usually) very good C and C++ programmers onto the
project. While generally experienced, these folks had very
little experience with kernel-level programming, and almost none
in Rust. For the OS bits, we were pointing them at MIT's course
materials for the 6.828 course, but those were in C and for
32-bit x86, so I rewrote it in Rust for x86_64.
In doing so, I took care to stay as close as I reasonably could
to the original. Obviously, some things are different (most
system calls are implemented as methods on the `Proc` type, for
example, and error handling is generally more robust; there are
some instances where the C code will panic in response to user
action because it's awkward to return an error to the calling
process, but I can bubble thus back up through the kernel and
into user space using the `Result` type), but the structure is
largely the same; my only real conceit to structural change in
an effort to embrace modernity was the pseudo-slab allocator for
pipe objects. Indeed, there are some things where I think the
rewrite is _less_ elegant than the original (the doubly-linked
list for the double-ended queue of free buffers in the block
caching layer, for instance: this was a beautiful little idea in
early Unix, but its expression in Rust -- simulated using
indices into the fixed-size buffer cache -- is awkward).
I can certainly see that some things are more inconvenient to write in
C, even in modern C standards and styles - Rust's Result types are much >nicer to use than a manual struct return in C. (C++ has std::expected<> >that is very similar to Result, though Result has some convenient
shortcuts and is much more pervasive in Rust.)
The Rust port did expose a few bugs in the original, which I
fixed and contributed back to MIT. And while it's true that the
xv6 code was initially written in the mid 00's, it is still very
much used and maintained (though MIT has moved on to a variant
that targets RISC-V and sunsetted the x86 code). Also, xv6 has
formed the basis for several research projects, and provided a
research platform that has resulted in more than one
dissertation. To say that it is not representative of modern C
does not seem accurate; it was explicitly written as a modern
replacement for 6th Edition Unix, after all. And if it is not
considered modern, then what is?
Modern C would, IMHO, imply C99 at the very least. It would be using
C99 types, and it would be declaring local variables only when they can
be properly initialised - and these would often be "const". It would be >using enumerated types liberally, not a bunch of #define constants. It >would not be declaring "extern" symbols in C files and other scattered >repeated declarations - rather, it would be declaring exported
identifiers once in an appropriately named header and importing these
when needed so that you are sure you have a single consistent
definition, checked by the compiler. It would not be using "int" as a >boolean type, returning 0 or -1, or when an error enumeration type would
be appropriate. It would be organised into directories, rather than
mixing the OS code, build utilities, user-land programs, and other files
in one directory. Header files - at a minimum, those that might be used
by other code - would have guards and include any other headers needed. >Files would have at least a small amount of documentation or
information. All functions would be either static to their files, or >declared "extern" in the appropriate header.
And for code like this that is already compiler-specific, I would also
want to see use of compiler extensions for additional static error
checking - at least, if it is reasonable to suppose a compiler that is >modern enough for that.
Now, I realise some of these are stylistic choices and not universal.
And some (like excessive use of "int") may be limited by compatibility
with Unix standards from the days of "everything is an int".
None of this means the code is bad in any particular way, and I don't
think it would make a big difference to the "code safety". But these
things do add up in making code easier to follow, and that in turn makes
it harder to make mistakes without noticing.
I hear this argument a lot, but it quickly turns into a "no true
Scotsman" fallacy.
Agreed - that is definitely a risk. And it also risks becoming an
argument about preferred styles regardless of the language.
This is less frivilous than many of the
other arguments that are thrown out to just dismiss Rust (or any
other technology, honestly) that often boil down to, honestly,
emotion. But if the comparison doesn't feel like it's head to
head, then propose a _good_ C code base to compare to Rust.
I don't know of any appropriate C code for such a comparison. I think
you'd be looking for something that can showcase the benefits of Rust - >something that uses a lot of dynamic memory or other allocated
resources, and where you have ugly C-style error handling where
functions return an error code directly and the real return value via a >pointer, and then you have goto's to handle freeing up resources that
may or may not have been allocated successfully.
Ideally (in my mind), you'd also compare that to C++ code that used
smart pointers and/or containers to handle this, along with exceptions >and/or std::expected<> or std::optional<>.
I am totally unconvinced by arguments about Rust being "safer" than C,
or that it is a cure-all for buffer overflows, memory leaks, mixups
about pointer ownership, race conditions, and the like - because I
already write C code minimal risk of these problems, at the cost of >sometimes ugly and expansive code, or the use of compiler-specific code
such as gcc's "cleanup" attribute. And I know I can write C++ code with >even lower risk and significantly greater automation and convenience.
If Rust lets me write code that is significantly neater than C++ here,
then maybe it worth considering using it for my work.
First, however, the language and tools need to reach some level of
maturity. C++ has a new version of the language and library every 3
years, and that's arguably too fast for a lot of serious development
groups to keep up. Rust, as far as I can see, comes out with new
language features every 6 weeks. That may seem reasonable to people
used to patching their Windows systems every week, but not for people
who expect their code to run for years without pause.
On 30/07/2025 13:30, Dan Cross wrote:
In article <106cf06$32d5u$1@dont-email.me>,Without taking any sides here, it is easy to make the mistake of
Richard Heathfield <rjh@cpax.org.uk> wrote:
[snip]
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 :-)
I'd say, give it a whirl. You may feel the same, but you may
also be pleasantly (or perhaps unpleasantly!) surprised. In any
event, I'd like to know how it turns out.
- Dan C
On 05.08.2025 00:33, Dan Cross wrote:
I'd say, give it a whirl. You may feel the same, but you may
also be pleasantly (or perhaps unpleasantly!) surprised. In any
event, I'd like to know how it turns out.
- Dan C
Circumstances limit me from giving a detailed reply here. But I do want
to thank you for your time and the information and experiences you have >shared here. Perhaps precisely because you are not evangelising, you
are a lot more convincing than many things I have read. It will take me >some time before I can give Rust a fair trial for my coding, but I will >definitely see how I can fit it in, and compare it to how I work now in
C and C++.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 149:56:08 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
437 files (114M bytes) |
| Messages: | 2,410,966 |