Re: The Case for Rust (in the base system)

From: David Chisnall <theraven_at_FreeBSD.org>
Date: Tue, 23 Jan 2024 09:41:01 UTC
On 22 Jan 2024, at 22:45, Robert R. Russell <robert@rrbrussell.com> wrote:
> 
> Having had the luxury or curse of not being stuck with only one
> programming language I have learned usable pieces of several. C++ is
> not on that list even though I have the most formal education in it.
> My best way of answering why is this. Would you write or use a C++
> codebase maintained by the average developer with just Vi? Up to C++03
> I can say yes, after that the answer is no.

I have no idea what this means.  There’s absolutely nothing in newer C++ that makes it harder to write with a text editor.  There is a lot that makes it easier to write correctly.

For reference LLVM is about 4MLoC (and about 5M lines of comments, something that FreeBSD could definitely learn from) and is written in modern C++.  I don’t think I’ve ever used an editor other than vim to work on it.  I don’t use nvi, because it’s not the ‘80s anymore.

I use ALE with vim, which integrates with clangd via LSP and provides autocompletion and error reporting for anything that can generate a compile_commands.json.  That’s not specific to C++.  I wouldn’t want to write C without syntax highlighting, autocompletion, or live error checking either.  It’s possible to do so for C or C++, but you’ll be less productive.

> A consequence of Microsoft's "Welcome back to C++" item that may have
> gotten missed is what resources are they spending to enforce compliance
> with a certain C++ standard?

I have no idea what this means.  ‘Compliance with a certain C++ standard’ is a thing that your compiler tells you when you try to compile.  

> Particularly, to enforce the restrictions on anti-patterns?

That varies from project to project.  I generally use clang-tidy and clang-format in pre-merge hooks in CI for the projects that I worked on at MS and that I work on personally.  And, of course, code review.  Automated tooling is no substitute for code review.  

> Cargo needs approximately a dozen lines in a
> configuration file to restrict its upstream sources. That includes
> whitespace and formatting.


Here is the script that runs formatting and static analysis across a codebase that I maintain:

https://github.com/microsoft/cheriot-rtos/blob/main/scripts/run_clang_tidy_format.sh

Almost all of the complexity is in *not* running it on files that we have imported from elsewhere or where, for compliance with external standards, we don’t want to enforce our naming rules, and for finding the relevant toolchain files.  The actual checker bit is right at the end.

Most projects run this kind of check through their build system, but we wanted to run it on headers in isolation as well as on full compilation units.  

David