From nobody Fri Sep 6 13:20:06 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X0cKN1M6Bz5V34c for ; Fri, 06 Sep 2024 13:20:08 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X0cKM6lkwz4HPn for ; Fri, 6 Sep 2024 13:20:07 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 36176 invoked by uid 89); 6 Sep 2024 13:20:07 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 6 Sep 2024 13:20:07 -0000 Content-Type: multipart/alternative; boundary="------------pFGvu7x3n00KwKyCXnuP6kOy" Message-ID: Date: Fri, 6 Sep 2024 09:20:06 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: David Chisnall , Poul-Henning Kamp Cc: Alan Somers , Dmitry Salychev , freebsd-hackers@freebsd.org References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X0cKM6lkwz4HPn 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 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 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 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--