Re: The Case for Rust (in any system)

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.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/