Date: Fri, 6 Sep 2024 09:20:06 -0400 From: Jan Knepper <jan@digitaldaemon.com> To: David Chisnall <theraven@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Alan Somers <asomers@freebsd.org>, Dmitry Salychev <dsl@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <cec3066b-b5f1-43bf-9ff6-4243d111e048@digitaldaemon.com> In-Reply-To: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------pFGvu7x3n00KwKyCXnuP6kOy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Second this.
(Not involved with C++ standardization, but closely follow it.)
On 9/6/24 03:41, David Chisnall wrote:
> 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).
>
Jan
--------------pFGvu7x3n00KwKyCXnuP6kOy
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Second this.<br>
<br>
(Not involved with C++ standardization, but closely follow it.)<br>
<br>
<div class="moz-cite-prefix">On 9/6/24 03:41, David Chisnall wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org">
<pre class="moz-quote-pre" wrap="">On 6 Sep 2024, at 08:25, Poul-Henning Kamp <a class="moz-txt-link-rfc2396E" href="mailto:phk@phk.freebsd.dk"><phk@phk.freebsd.dk></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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).
</pre>
</blockquote>
<br>
Jan<br>
<br>
</body>
</html>
--------------pFGvu7x3n00KwKyCXnuP6kOy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cec3066b-b5f1-43bf-9ff6-4243d111e048>