It is annoying that you lose all the standard dynamically allocated collections, etc. and need to fork the libraries if you don't want method variants panicking on OOM.
So, for example, you'd want Vec::push(x) to return Option<T> or Result<T, E> to get back `x` on alloc failure.
Conversation
As a language, it fully supports it. It fits well into the idiomatic error handling system based on sum types (typically Result) including syntactic sugar for bubbling up the errors.
Unlike C++, no-unwind support is standard, but high level stdlib mostly relies on panic on OOM.
1
The high level stdlib has no relevance to the kernel usage because it MUST use $![no_std] (freestanding) code. The high-level stdlib (libstd) uses lower-level standard libraries (libcore, liballoc, etc.) and they can use some of those, but they will need a stripped down liballoc.
1
So, basically, the only issue is they haven't yet forked liballoc to delete the methods doing panic on OOM. It's the same reason they need other placeholder stubs doing panic to fill in APIs used by stdlib code they've included via libcore, etc. Could fork libcore and delete it.
2
I don't know about the practicality of having to fork and maintain a likely incompatible version of rust, just for the Linux kernel.
2
They don't have to fork Rust. No language changes are required. The standard compiler works fine. They do need to implement allocation APIs, collections and the infrastructure for writing Linux kernel drivers. A lot of the point is making enforced safe APIs for those things.
1
They don't use the C standard library at all in the Linux kernel because it's ill suited to it and doesn't support freestanding use. They have to implement it themselves and make their own APIs.
They can use libcore for Rust, which they don't get with C. They can't use libstd.
1
Oh I see. It might even result in a better language, who panics on OOM anyway? its insane.
1
doc.rust-lang.org/alloc/ is the library they have to fork. They mostly need to delete the APIs using panic on OOM, rename the ones reporting errors to use the freed up simpler names and add some missing ones. It's not a very large task.
1
The reason they were able to use the standard liballoc at all is because it allows you to supply the low-level dynamic allocator. It implements higher level APIs. So, they wrapped the kernel allocator.
Functionality in liballoc is higher-level than anything provided by C stdlib.
2
If you know modern C++, Box<T> is std::unique_ptr<T>, Rc<T> is a thread-local std::shared_ptr<T> (no atomics), Arc<T> (in libsync) is std::shared_ptr<T>, Vec<T> is std::vector<T>, etc.
Unlike C++, it's memory safe and doesn't have inherent overhead. It's also more interoperable.
The language has an unsized slice type [T] which you combine with a pointer like &[T] for an unowned view.
So, for example, Vec<T> just provides stuff related to allocation and gets coerced to &[T].
Box<[T]> (rarely ever used in practice) can be converted to and from Vec<T>.
1
&[T] or Box<T> are (pointer, length). Vec<T> is (pointer, length, capacity).
For cases where there have to be dynamic checks for normal methods, there are also unsafe versions of those usable in unsafe { ... }. Rarely useful, but there if optimizations fail you and you need it.