Date: Fri, 6 Sep 2024 08:41:44 +0100 From: David Chisnall <theraven@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Alan Somers <asomers@freebsd.org>, Dmitry Salychev <dsl@freebsd.org>, Jan Knepper <jan@digitaldaemon.com>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> In-Reply-To: <202409060725.4867P3ul040678@critter.freebsd.dk> References: <202409060725.4867P3ul040678@critter.freebsd.dk>
index | next in thread | previous in thread | raw e-mail
On 6 Sep 2024, at 08:25, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > I will also note that almost all the blame for C's current status > lies with the standardization efforts, which almost seem hell-bent > on destroying the language rather than improving it. As someone who is involved with C++ standardisation and so periodically hears things from WG14, my impression is that the people who care about the things that you list have all moved to C++, where they were solved problems at least a decade ago. The people still actively driving C are the people who didn’t leave because they don’t want these things (and, increasingly, C++ people who just want to make sure that C doesn’t diverge too much from being a subset of C++). It’s trivial to write a packed struct in C++ where the fields are all BigEndian<T> that do byte swapping on implicit conversion to and from T, for example. Integer ranges can be implemented in the same way and there is a proposal to add them to the standard library that looks nice (the ranged integers are a small part, the proposal is mostly about units and quantities). Having written a kernel in C++, and worked on two in C, and read a reasonable amount of one written in Rust, I am firmly of the opinion that C is absolutely the worst choice for writing a kernel. This was not true in the ‘80s and it wasn’t true even 15-20 years ago, so the question is how to move from where we are to where we should be. The strategy document that I coauthored at Microsoft recommended the following: - C++ conforming to the Core Guidelines and with static analysis for existing C/C++ projects with the C parts incrementally migrated to C++. - Rust, C#, or TypeScript for new projects and discrete new components with well-defined interface boundaries. - No new C code, except in open-source projects that accept only C contributions. That’s probably not quite the right shape for FreeBSD (at the very least, I’d recommend Lua instead of C# or TypeScript in most places). Davidhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD>