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

On Tue, 23 Jan 2024 15:04:31 +0000
David Chisnall <theraven@FreeBSD.org> wrote:

> On 23 Jan 2024, at 14:55, Robert R. Russell <robert@rrbrussell.com>
> wrote:
> > 
> > The specific anti-patterns is was thinking of in both instances is
> > called Meta Template Programming. Back in C++03 I just used the
> > template system as a form of generics. In that role it works well
> > and with the new smart pointers definitely improves some of the
> > older problems C++ had.  
> 
> Template metaprogramming is a core feature of C++, and more recent
> versions have added constexpr / consteval / constinit and concepts to
> make it a lot more readable.  It can be abused, but it is not, in
> itself, bad.  My example from earlier in the thread used template
> metaprogramming to do compile-time checks of correctness of the
> overflow / wrapping behaviour of a ring buffer.  Making it easy to
> check properties of your code at compile time is very much a feature,
> not an antipattern and it’s hard to see how you could argue the
> converse without arguing that bugs are a good idea.
>
> 
> > However, C++ definitely has a complexity cult and a ricer cult in
> > its community. The overlap between the two appears to be fairly
> > large which worries me.  
> 
> Non-specific ad-hominem arguments are tremendously unhelpful.

It sounds like I could read the code you talked about and grasp what
the intention was even if I didn't understand exactly how you were
achieving the task. The groups I was commenting about have a preference
for people not being able to do that. The "Ricers" use speed as their
justification.

> > I have less reservations about C++ than I did earlier, though I
> > think the build system may require major surgery to support it
> > well.  
> 
> The build system for both userspace and the kernel already support
> C++.  I have written a kernel module in C++ in the past.  Currently,
> there’s no mechanism in the kernel loader to support COMDATs (and I
> don’t really want to add it, I’d much rather handle them as an
> install-time preprocessing step for kernel modules), so you can’t
> load kernel modules that use inline functions / variables, but that’s
> orthogonal to the build system.
> 
> David
> 

I was mainly thinking about handing things like setting the proper
variables so the LSP servers work or being able to do some static
analysis before commits.