Rust in the kernel is no longer experimental
181–190 of 853 posts
Re: Rust in the kernel is no longer experimental
#182Earlier quoted context omitted.
Zig at least claims some level of memory safety in their marketing. How real that is I don't know.
I'm unaware of any such marketing.
> ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free
which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".
Re: Rust in the kernel is no longer experimental
#183Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)
Re: Rust in the kernel is no longer experimental
#184Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
Re: Rust in the kernel is no longer experimental
#185Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?
Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.
Apple has invested in Swift, another high level language with safety guarantees, which happens to have been created under Chris Lattner, otherwise known for creating LLVM. Swift's huge advantage over Rust, for application and system programming is that it supports an ABI [1] which Rust, famously, does not (other than falling back to a C ABI, which degrades its promises).
[1] for more on that topic, I recommend this excellent article: https://faultlore.com/blah/swift-abi/ Side note, the author of that article wrote Rust's std::collections API.
Re: Rust in the kernel is no longer experimental
#186Re: Rust in the kernel is no longer experimental
#187Re: Rust in the kernel is no longer experimental
#188Re: Rust in the kernel is no longer experimental
#189I need to check the rust parts of the kernel, I presume there is significant amounts of unsafe. Is unsafe Rust a bit better nowadays? I remember a couple of years ago people complained that unsafe is really hard to write and very "un-ergonomic".
Re: Rust in the kernel is no longer experimental
#190Earlier quoted context omitted.
Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.
That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then R…