Re: If Linus had known Rust 30 years ago ....
> Do we really want things like "trait objects" and "fat pointers" in an operating system? The code is difficult enough to debug as it is, without introducing opaque abstractions. I think you're making my point for me.
My points were that:
1. You can already do this in C and, from what I remember, the Linux kernel already has these sorts of things where it's deemed appropriate... just with extra clutter because the language doesn't know them natively. (Sort of like the syntactic bloat Glib-based libraries like GTK see to implement C++-style OOP in C.)
2. Rust's design is pretty good at making dynamic dispatch and trait objects feel unappealing unless you actually need them. I think the only fat pointers that get used regularly are slices, which are (*data, len) fat pointers to subsets of strings or arrays. (They're great for zero-copy parsing.)
3. Unlike C++, Rust's support for polymorphism doesn't require you to be on your guard about whether the definitions of data structures have been modified. It's just a helper so your vtables and function pointers can play more nicely with any generic container types you might implement.
> Besides, even if the OOP in Rust is light weight at the moment, there's no guarantee that it will stay that way. The language isn't even standardised yet. What's to stop some clever person adding C++-style OOP to Rust "because it makes programming so much easier"?
1. Over the last decade, the RFC process has demonstrated that the Rust team aren't swayed by "because it makes programming so much easier". Heck, one of the things they've actively been focusing on is a proposal's effect on the language's complexity budget.
2. People have been clamouring for it for a decade now. The Rust team has stood fast on "There's no single design that's objectively better than the others, and all of them make trade-offs. We'll revisit this discussion when one of the implementations of this (via procedural macros) on crates.io has seen runaway success". (And none of them have. It turns out that classical inheritance is one of those things that people are loud about, but there's underwhelming little in-the-wild use of compared to other things implemented as procedural macros.)
3. Why did Rust add async/await keywords when you could do it using the futures crate? Not because the futures crate was a pain to use... but because it was demonstrated that it needed to be a first-class language construct for the borrow checker to behave in non-hair-tearing ways when you wanted to hold borrows across await points.
4. The whole reason Rust doesn't have an official, toolchain blessed executor for the async/await keywords is because they want it to remain suitable for both embedded and big-scale servers.
5. The Rust team have strong opinions that features added to the language must be orthogonal and harmonious. That makes adding C++-style OOP highly unlikely because it would overlap too much with the existing design.
6. Standardization does nothing to prevent a language from adding footgun-oriented programming features... it just means they have to live within the undefined/implementation-defined portions of the spec, or be stuff that wouldn't compile in a purely standard-following implementation.
> Is it really? I wasn't aware of this. I believe Linux has been built using Intel's C compiler. Can you give me an example of the use of non-standard "GNU C" in, say, Linux 6.6.52? That is, a file name, line number, and a short description of the quirk? I'd be most interested to see this.
I'll do one better. Here's a blog post that does a run-down of the GNU extensions Linux depends on, including example code snippets:
https://maskray.me/blog/2024-05-12-exploring-gnu-extensions-in-linux-kernel
Both LLVM Clang and ICC have implemented a bunch of those extensions with the intent of being able to compile the Linux kernel. (Getting those extensions implemented was the lion's share of what the project to get the Linux kernel building on LLVM Clang was doing... though there was also patching done to retire use of ones the kernel devs were less fond of than they used to be. For example, the kernel was using GNU C's pre-C99-style Variable Length Array support and removing that, though desirable in its own right, also avoided the need to implement them in Clang. I think the project was called LLVMLinux but it's been a while.)