Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16836

Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?)

Show all headers | View raw

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:
>>> 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.
> 

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.

>> (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.
> 

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 07:46 -0400
  Re: Informal discussion: comp.lang.rust? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-10 07:14 -0700
    Re: Informal discussion: comp.lang.rust? Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-10 16:42 +0000
      Re: Informal discussion: comp.lang.rust? c186282 <c186282@nnada.net> - 2025-06-18 02:51 -0400
        Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 11:37 +0000
          Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-28 13:50 +0200
            Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 15:16 +0000
              Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-28 17:59 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 22:18 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 10:18 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 12:16 +0000
                Re: Informal discussion: comp.lang.rust? David Brown <david.brown@hesbynett.no> - 2025-07-29 17:37 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 18:24 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 19:14 +0200
                Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 18:27 +0000
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) David Brown <david.brown@hesbynett.no> - 2025-08-02 17:47 +0200
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-04 22:33 +0000
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) David Brown <david.brown@hesbynett.no> - 2025-08-06 18:38 +0200
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 03:30 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 19:08 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:00 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 20:34 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:40 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 20:51 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:53 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-09-05 10:59 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-08-03 17:55 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-08-03 18:17 +0200
              Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-29 06:24 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 12:27 +0000
                Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-30 07:44 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 11:30 +0000
                Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-30 16:51 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:00 +0000
                Re: Informal discussion: comp.lang.rust? David Brown <david.brown@hesbynett.no> - 2025-08-02 18:41 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-04 22:34 +0000
  Re: Informal discussion: comp.lang.rust? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-10 17:35 -0400

csiph-web