On 03 Dec 2025 at 11:13a, Nightfox pondered and said...
Re: Re: macOS 26
By: tenser to Nightfox on Thu Dec 04 2025 07:20 am
Rust is, frankly, a better language than either C or C++, but with go reason: it had 35 years of C and 30 years of C++ history to learn fro when it was designed. Plus it could also draw on lessons learned fro research in the wider PL community over those decades. But it's easy do better when you've got so much data you can learn from.
I don't doubt Rust is a good language. I have yet to try it myself; that's mainly because I haven't worked on a project that uses Rust, and
I haven't really looked into using it for one of my own projects.
At the same time, sometimes I'm not sure about a programming language forcing certain rules & paradigms, etc..
All programming languages force rules, paradigms, idioms, etc, on
programmers. Even assembly languages do this. C, for example, has
some very abstruse rules for the promotion of integers of various
types to other types; these can often surprise people who aren't
used to them. For example, pop quiz:
uint16_t mul(uint16_t a, uint16_t b) { return a * b; }
Is this little function portable and well-defined?
C and C++ let you do pretty
much anything, and IMO that's not necessarily a bad thing.
Well, except that they kinda sorta really don't. I mean,
on some level they're all Turing-complete; in the limit I
can write a Rust interpreter in C, but that's not a
particularly useful thing in the context of workaday
programming. But on a more practical level I cannot, for
example, directly manipulate the frame pointer in C code;
I need to jump to assembly for that (whether inline or
some other way).
But what people tend to mean when they say such things is
that, in C, they're programming at a very low level, and
can thus manipulate the state of the machine in a much more
direct way than in, say, Python or Java. But that's ALSO
not really true, because 9 times out of 10, programs that do
that kind of thing need to rely on some sort of externally
defined standard (e.g., an ABI like the SVR4 one to define
the size and alignment requirements of primitive types, and
define the details of structure layout and function calling
conventions). And when doing so, one has to be _really_
careful to avoid the dreaded, "Undefined Behavior". I've
seen C programs that have "worked" for decades suddenly
break when a compiler got a point revision, because it
turned out the program relied on the compiler behaving a
certain way for UB, and all of a sudden the compiler started
treating that differently. A lot of programs that people
think are "correct" are really only correct on accident
because older compilers had relatively sensible behavior for
things like signed integer overflow, aliasing, and so on.
I've written a couple of kernels in Rust (and of course some
assembly code) and the bits of C that make it usable to
manipulate low-level state are _also_ available in Rust.
*Plus* I get goodies like iterators, sum types, type-safe
IO, bounds-checked slices, pattern matching, parametric
polymorphism, closures, sensible scoping rules, explicit
type conversions (with error checking!), language-level
support for error checking via the Result monad and `?`
operator, traits, built-in support for unit testing, and
so on, that I just don't get in C. The canonical build
system even supports a robust library ecosystem.
Some of these I can get in C++, but not all; it's like the
Rust designers sat down and said, "gee, what would it look
like if we designed a language that fixed the major problems
in C++ that we've observed over the last 20 years?" :-D
Just be
careful not to do stuff that will cause bugs. :) I know, there's always human error, and everyone will eventually make mistakes, so I suppose
it's good if the language can help avoid that.
That's really the thing. 50 years of experience have shown that
our best and brightest programmers write buggy C and C++ code.
"Just write correct code" simply doesn't work, even for some really
brilliant people. The best engineers know that the most robust
artifacts come from using many approaches to improving quality:
better languages, better practices, better tools, etc. These are
not training wheels on a kids' bike, they're chain guards for power
tools.
Sometimes I'm torn
between that and the adage that "it's a poor craftsman who blames his tools". There's the old joke that a person goes to see a doctor and
says, "My arm hurts when I move it like this," and the doctor says,
"Then don't move it like that."
Ah, but the skilled craftsman also carefully curates, maintains,
and selects the tools for the job at hand. It is the poor craftsman
who reaches for a hammer when a screwdriver is called for.
The experienced craftsman is always looking for newer, better tools,
and understands that often the safer tool yields the better finished
product: the bespoke jig for moving the large panel across the saw
allows the craftsman to concentrate on the cut itself, because the
piece is secured and won't kick-back, as it is not being forced
through at an angle. Similarly, the plane iron is kept sharpened
and clean, and the sole waxed and square. Not only is this safer,
the resulting work is higher quality.
I don't, generally, remove the guard from my chainsaw, even though
I try to be very careful when I use it. Why should I treat the tools
that I program with differently?
These conspiracy-theories about control, evangelism, attacks on softw freedom, etc, are just uninformed nonsense.
Honestly this thread is the first time I've heard about any conspiracy theories about control on software freedom due to evangelism of a programming langauge..
The Rust-in-Linux people have faced a lot of resistance from a
number of long-time developers who are resistant to moving away
from C; most of that is FUD. But it gives fuel to a number of
ankle-biters swirling around the Linux community make these
sorts of wild claims, but they don't tend to produce a lot of
software: no one takes those people seriously.
Similarly, Rust does have a problem with too many fanbois who
blame _all_ software problems on failure to write everything in
Rust. Those folks _also_ don't tend to write a lot of software,
and again, no one takes them seriously. But their behavior
tends to interact with the Linux peanut gallery types to create
a pretty toxic mix, and amps them all up. The result is a lot
of noise and heat, and almost no code, but everyone else has to
wade through this ridiculous and unnecessary cesspool.
Torvalds seems pretty bullish about Rust in the Linux kernel,
though, so we'll see where it lands up; OTOH, the maintainers
keep burning out and quiting because of the FUD and the
crazy nonsense.
--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)