Ok maybe I was user pointers wrong in Rust. And I must confess that I never really understood lifetimes either, however
* I don't think that low level code needs to be "messy", and
* I don't think that adding an abstraction on top solves anything complexity wise.
For memory paging I used to have a whole library in Rust that handled hierarchy of page tables with very abstract pagetable classes and interfaces [0]. Now I just have 80 lines of zig that handles everything [1]. I much prefer the latter.
> I think this is reasonable even for kernel code.
It's not, for some of the reasons that Linus doesn't want C++ code in the kernel [2]
The Rust code you wrote seems to be extremely heavy on boilerplate. A couple of macros could have drastically reduced the line count.
I don't think what Linus wrote in 2004 on C++ has much relevance for 2020 Rust, especially for a new kernel that doesn't have a ton of contributors. Most of his complaints seem to be on how C++ abstractions can make it hard to review unknown code and how 2004 C++ code bases often had extremely messy code. Rust IMO doesn't suffer from those problems near as much as 2004 C++ did.
Also, Google is using Rust for part of their new Fuchsia kernel so at least they think Rust has something good to offer kernel dev.
Small nitpick: Google isn't using Rust for the Fuchsia kernel. The kernel, Zircon, is written entirely in C and is based on Little Kernel. Google is using Rust for some userspace drivers (Fuchsia being a micro-kernel).
No, it's written in C++[1]. They're very different languages.
That said, Google seems to think C++ has something to offer to all kinds of development. It seems to work for them, but they are a heavily C++ shop. I wouldn't read too much out of their use of C++ anywhere; it'd be more surprising and interesting to see them use anything else.
Oh that's interesting. Zircon is based on LK[0] which is in C, which is why I thought it was still written in C. I wonder how much is left of the original LK code then.
You might find it helpful to look at Redox OS and Tock to see how they're handling kernel development in Rust. May or may not be easier than what you described.
* I don't think that low level code needs to be "messy", and
* I don't think that adding an abstraction on top solves anything complexity wise.
For memory paging I used to have a whole library in Rust that handled hierarchy of page tables with very abstract pagetable classes and interfaces [0]. Now I just have 80 lines of zig that handles everything [1]. I much prefer the latter.
> I think this is reasonable even for kernel code.
It's not, for some of the reasons that Linus doesn't want C++ code in the kernel [2]
[0] https://github.com/gz/rust-x86/blob/28d5839933973e0b639ef354...
[1] https://git.sr.ht/~jzck/kernel/tree/master/src/arch/x86/pagi...
[2] https://yarchive.net/comp/linux/c++.html