Re: The Case for Rust (in any system)

Karl Denninger <karl@denninger.net> writes:

> [[PGP Signed Part:Undecided]]
> 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.
>
> 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.
>
> 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.

Well said.

Personally, I wouldn't argue that people tend to do stupid thing with
the tools given, but putting everyone in diapers is just _one_ possible
way to solve the problem.

If Rust is somehow considered to be brought deep down in the FreeBSD
kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and
MISRA C++:2023.

Regards,
Dmitry

-- 
https://wiki.freebsd.org/DmitrySalychev