Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Sep 2024 19:20:32 +0000
From:      Paul Floyd <paulf2718@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: The Case for Rust (in any system)
Message-ID:  <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.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


On 06-09-24 07: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++).

+1. SG23.

There is one prominent case of someone moving from C++ to C 
standardization to get a proposal that was rejected in C++ adopted in C.

I have seen some papers with proposals to improve C's memory safety but 
I doubt that they will ever get off the ground. C++ code that follows 
the core guidelines is already very substantially more secure than C. 
SG23 is working on improvements.

> 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++

Out of curiosity, did that mean limiting the ABI use (no RTTI or 
exceptions). Did it also allow using different compilers (say clang and 
GCC)?

 > 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.

Sounds like good suggestions to me.

A+
Paul




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5d707cd5-ee31-4cce-98b7-3826e891a2dd>