Re: The Case for Rust (in any system)

On Thu, Sep 5, 2024 at 1:20 PM Karl Denninger <karl@denninger.net> wrote:
>
> On 9/5/2024 14:09, Alan Somers wrote:
>
> By now I expect that most of you have seen the long list of new
> security advisories that just came out.  Strikingly, all were the
> result of memory handling errors.  And none of them wouldn't have
> happened if their respective programs had been written in a
> memory-safe language.
>
> In fact, of all the C bug fixes that I've been involved with (as
> either author or reviewer) since May, about three quarters could've
> been avoided just by using a better language.
>
> The real takeaway here is that C is no longer sufficient for writing
> high quality code in the 2020s.  Everyone needs to adapt their tools.
> Programmers who don't will increasingly come to resemble experimental
> archaeologists, i.e. people who learn flintknapping to "keep the
> knowledge alive".  Such people are valuable, but definitely niche.  I
> for one don't want my career to go in that trajectory.
>
> I'm sorry, this is not the correct take from it.
>
> To argue that the answer is to put a diaper on a child so it does not drop excrement on the carpet is to forever treat said human as an infant without control of its sphincters.  While such an answer might be necessary for a short period of time in all young human creatures it also should be obvious that we are all walking around today without them and thus said prophylaxis is to cover for a deficiency rather than a necessity.

Do you think that all of those bugs were introduced by novice
programmers who hadn't yet learned "control of sphincters"?  I don't.
They were all professionals.  These are the kinds of mistakes that all
C programmers make from time to time.  No human can write perfect
code, no matter how experienced.

>
> Now if the prophylaxis had no cost it wouldn't matter so much, but it does have cost (just as do diapers) in that such languages are inherently less-efficient.  There is an argument for this trade-off where the "thing" is infrequently used and thus the impact small, but going this route for frequently-used applications and even worse at the OS level is how we got to a place in many application programs and operating systems where what used to run comfortably in under a gigabyte of RAM will no longer execute at all in four, and why an application (when written in "C") will handle multiple camera streams in real time with five-minute lookback buffers, has its own defensive systems against attack and denial-of-service and internal HTML-capable server on a $25 postcard-sized computer, were it to be written in such a "safe" language would also require a device with five times the CPU, RAM -- and electrical consumption due to the overhead imposed by same.

I think you are misinformed about the runtime costs involved.  In
fact, Rust's overhead is quite low.  According to the most famous
comparison of programming languages, it runs basically at the same
speed as C and C++.  Rust is often critized for the size of its
binaries, but as we've discussed on this list, that's mostly due to
the amount of debugging stuff crammed in by default.  Those defaults
are reasonable for anybody using a modern computer, but embedded
developers can easily turn them off.  And one of the coolest things
about Rust compared to earlier languages like Modula3 is how much of
error-checking happens at compile time.  It's really quite good.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html

>
> Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not" should not, in my opinion anyway, end in the latter decision.

Bugs like this are quite frequent in the FreeBSD code base.  So by
your logic, we must not have "programmers of higher skill" and
therefore we should be relying on more advanced programming languages
to "fix the stupidity".  Point taken.