Strongly disagree. User friendly doesn't mean "short", it means "accessible for newcomers" in this context. And the rust book very much is that: it starts out extremely basic/simple and builds from there. Anecdotally and for many others it's been the best way to develop a solid understanding of the language.
Rust is somewhat "shortcut resistant" for new learners: you can pick it up by just starting coding after reading a few blog-post-length tutorials and backfilling understanding, the way many people do with other languages, but this typically takes much longer and incurs more frustration with Rust than, say, Python. That's because Rust takes longer to understand than most languages (I say this as someone who enjoys the language and expects it to become quite widely used, not as a criticism). Hence the book: it's long, but quite friendly. It's just not what you'd expect if you compare it to other learn-a-language-in-x-hours experiences.
I disagree - I found the book to be very valuable when learning Rust. I agree it would not be good if Rust is your first programming language. But I think many beginners to Rust are people who are already experienced programmers and basically just want to know some mental models for how Rust's memory model works, some useful idioms and patters, "how to do X in Rust", and how to get started.
They're approximately as safe as modern Docker is. Upside to Docker: more security knobs (eBPF, kernel MAC, &c); upside to jails: probably easier to get right out of the box, fewer footguns. Both jails and containers (and Solaris Zones) share a fundamental security weakness, which is a kernel shared between tenants.
Counts what you are afraid against. There's always some side channel attack that could possibly used to gain information, even on VM's this is true. Off the top of my head there could be some timing attack to gain information on which libraries others are using by reading in libraries and seeing if they are warm in the buffer cache, counts if you care about sharing the same kernel. I generally find them secure enough considering how fast they can be brought up and down.
The fundamental thing about those features (and the equivalent on every system except Windows) is that you can never get more capabilities, only less. Once you are in a jail, there is no API for getting out of it.
You can't even see a binary from the rest of your system, and exec won't get you out.
There is no reason that Rust doesn't share the same infrastructure problems. The main difference is that the kernel maintainers want Rust in the kernel, while if you want to maintain a module written in C++ then you are on your own.
Community wise, yes. It seems to have gained some momentum.
From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if only because you can normally just include the headers and be done with it.
(Although as the article says, there are some cleanup to do.)
From an everything point of view, there's no point in adding complexity for no tangible benefit. Rust has tangible benefits (memory safety). Very far from a silver bullet, but demonstrably better than C.
Rust isn't being experimented with in the kernel because someone decided we should really add a second language. C++ interop with C doesn't matter when there's no reason to use C++ in the kernel anyway.
The "interoperate easier" idea is a trap for both C and C++ and worth avoiding because in fact they aren't quite compatible, so you're making both languages worse to achieve this. I don't much like C++, but if you must use C++, actually use C++ and forget that it's sorta kinda "compatible" with C.
I know they are not 100% compatible, but they are 99% compatible, and that's much better than Rust.
It's easy to make it compatible by not using fields called "class", or using #ifndef __cplusplus, most C library headers are actually like that. But not the Linux kernel because they refuse it.
That's why I'm saying that the choice is not a technical one.
You can create headers that are usable from C and C++, but you have to actively maintain it that way. As C headers tend to not have function definitions in them, it's fairly easy to avoid the C-only features.
I doubt that Linux headers give a damn about usability from C++ though.
