Date: Thu, 5 Sep 2024 13:49:33 -0600 From: Alan Somers <asomers@freebsd.org> To: Karl Denninger <karl@denninger.net> Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <CAOtMX2ioxXmQTRNBe9k6yEGi9cBYGNQ1dYjrtjUfWAMyMKEA2g@mail.gmail.com> In-Reply-To: <b2c6c38c-4e14-4e3e-b6ac-3f9c13519a0f@denninger.net> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <b2c6c38c-4e14-4e3e-b6ac-3f9c13519a0f@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 5, 2024 at 1:20=E2=80=AFPM 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 dro= p excrement on the carpet is to forever treat said human as an infant witho= ut 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 obvio= us that we are all walking around today without them and thus said prophyla= xis 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 doe= s 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 i= nfrequently used and thus the impact small, but going this route for freque= ntly-used applications and even worse at the OS level is how we got to a pl= ace in many application programs and operating systems where what used to r= un 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 cam= era streams in real time with five-minute lookback buffers, has its own def= ensive systems against attack and denial-of-service and internal HTML-capab= le 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-summar= y-charts.html > > Thus for kernel-level or system-library-level code (or for that matter ex= ecution-heavy applications) that are executed very frequently and thus impo= ses said cost all the time (or at least a very large amount of the time) th= e debate over "do it once and do it right, even if it takes longer and requ= ires programmers of higher skill" approach .vs. "do it fast and let the com= puter catch and fix the stupidity at runtime, imposing said cost in every i= nstance 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2ioxXmQTRNBe9k6yEGi9cBYGNQ1dYjrtjUfWAMyMKEA2g>