Date: Thu, 12 Sep 2024 16:59:27 -0700 From: "Pat Maddox" <pat@patmaddox.com> To: "Joe Schaefer" <joesuf4@gmail.com>, "David Chisnall" <theraven@freebsd.org> Cc: "Alan Somers" <asomers@freebsd.org>, Chris <bsd-lists@bsdforge.com>, "Warner Losh" <imp@bsdimp.com>, "FreeBSD Hackers" <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <b0d17cd4-e5af-41a1-8b50-df5f43989258@app.fastmail.com> In-Reply-To: <CAOzHqc%2By_NO9BG2ZAoKr9oA7iWU25nNFT1-y2Ug1%2BJZoCMpMSQ@mail.gmail.com> References: <CAOtMX2g_om8mW-xB855LNOHa8C0T5X0WtgMPc0TTr6TwiMEicw@mail.gmail.com> <A9A99648-EA30-4C63-A88B-3E9CC7CCFF35@freebsd.org> <CAOzHqc%2By_NO9BG2ZAoKr9oA7iWU25nNFT1-y2Ug1%2BJZoCMpMSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you have those reversed. I would say that a compiler that notifies you of errors is more empathet= ic than one that doesn't, inasmuch as the compiler's designers' empathy = is expressed through the tool. Knowing that we will write errors and can benefit from automated checks = expresses humility to me. The safety net of such checks allows us to explore new ideas. C's "don't want memory errors? don't write none" approach is clearly mor= e hostile and requires strict adherence to the rules. Pat On Thu, Sep 12, 2024, at 4:07 PM, Joe Schaefer wrote: > On the other hand, it is foolish to expect a programming language=20 > itself to be more thoughtful and wise than the engineers who need to=20 > solve a computational problem in the here and now. > > It=E2=80=99s like banking on building an empire based on process enfor= cement,=20 > civility, diversity of preferred quota stereotypes, and obedience;=20 > instead of empathy, humility, diversity of thought, and ingenuity. > > Rust is in the former camp; C the latter. All progress in this fad=20 > based universe leads to the same joy-free outcome of forever changing=20 > our toolchain to keep up with industry norms that treat professionalis= m=20 > in computer engineering as a market commodity. > On Thu, Sep 12, 2024 at 3:52=E2=80=AFAM David Chisnall <theraven@freeb= sd.org>=20 > wrote: >> On 12 Sep 2024, at 00:14, Alan Somers <asomers@freebsd.org> wrote: >> >=20 >> > "Memory safety =3D=3D restrictive training wheels" is just a common >> > misconception. >>=20 >> It=E2=80=99s worth thinking about why programming languages exist. An= y modern language is Turing complete. In terms of what can be expressed,= there is no difference between Rust, C, and C++. The important thing is= that there is an infinite set of possible programs and a finite set of = desirable programs. The goal of a programming language is to make it eas= ier to express programs in the set of desirable programs than ones that = are not in that set. Sometimes this is skewed away from specific sets. >>=20 >> The reason that we care so much about memory-safety bugs is that they= allow an attacker to step completely outside of the abstract machine of= the program. Unless you embed an interpreter/ compiler in your program,= memory-safety bugs are about the only way that an attacker can get arbi= trary code execution in your program. The kind of bug where an attacker = provides a specially crafted file / blob of network data and then runs c= ode on your machine is typically the worst thing that can happen. >>=20 >> Rust, in particular, skews towards making programs with memory-safety= bugs much harder to represent. You can still do it, by using unsafe or = relying on unsoundness in the type system as cve-rs does, but you have t= o try hard. >>=20 >> I consider that a desirable property in a language. I don=E2=80=99t h= ave to think about whether I=E2=80=99ve made these bugs impossible (and,= remember, WannaCry cost billions of dollars and depended on a single me= mory-safety bug), I get that for free and I can focus on other things. >>=20 >> David >>=20 >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b0d17cd4-e5af-41a1-8b50-df5f43989258>