Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

141–150 of 853 posts

Re: Rust in the kernel is no longer experimental

#141

Post by testdelacc1 »

ModernMech wrote: post #10
onedognight wrote: post #5

Earlier quoted context omitted.

It’s a bit clickbait-y, but the article is short, to the point, and frankly satisfying. If there is such a thing as good clickbait, then this might be it. Impressive work!

Might as well just post it: The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust-for-Linux team.

This should just be the pinned comment.

Re: Rust in the kernel is no longer experimental

#142

Post by ZeWaka »

vlovich123 wrote: post #130
jcranmer wrote: post #20

Earlier quoted context omitted.

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

Can you expand on bitfields? There’s crates that implement bitfield structs via macros so while not being baked into the language I’m not sure what in practice Rust isn’t able to do on that front.

Yeah, not sure what they're saying... I use bitfields in multiple of my rust projects using those macros.

Re: Rust in the kernel is no longer experimental

#143

Post by chasil »

lmm wrote: post #77
mmooss wrote: post #60

Earlier quoted context omitted.

Out of curiosity, do the LLMs all use memory safe languages?

Whenever the public has heard about the language it's always been Python.

The language that implements Python's high-speed floating point has often been FORTRAN.

https://fortranwiki.org/fortran/show/Python

Re: Rust in the kernel is no longer experimental

#144

Post by saghm »

obviouslynotme wrote: post #71
markus_zhang wrote: post #11

Not 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?

A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript. There will be small niches leftover: * Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers. * OS / Kernel - Nearly…

> No memory allocation means no Rust benefits

There are memory safety issues that literally only apply to memory on the stack, like returning dangling pointers to local variables. Not touching the heap doesn't magically avoid all of the potential issues in C.

Re: Rust in the kernel is no longer experimental

#145

Post by biorach »

markus_zhang wrote: post #11

Not 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?

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C.

For these cases you could always use Zig instead of C

Re: Rust in the kernel is no longer experimental

#146

Post by brabel »

littlestymaar wrote: post #89
ottah wrote: post #59

Earlier quoted context omitted.

I wouldn't be surprised to see zig in the kernel at some point

IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel. Rust is different because it both: - significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities. - And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld. That doesn't mean Zig is a bad language…

Zig as a language is not worth, but as a build system it's amazing. I wouldn't be surprised if Zig gets in just because of the much better build system than C ever had (you can cross compile not only across OS, but also across architecture and C stlib versions, including musl). And with that comes the testing system and seamless interop with C, which make it really easy to start writing some auxiliary code in Zig... and eventually it may just be accepted for any development.

Re: Rust in the kernel is no longer experimental

#149

Post by maweki »

ZeWaka wrote: post #142
vlovich123 wrote: post #130

Earlier quoted context omitted.

Can you expand on bitfields? There’s crates that implement bitfield structs via macros so while not being baked into the language I’m not sure what in practice Rust isn’t able to do on that front.

Yeah, not sure what they're saying... I use bitfields in multiple of my rust projects using those macros.

I'm not a rust or systems programmer but I think it meant that as an ABI or foreign function interface bitfields are not stable or not intuitive to use, as they can't be declared granularily enough.

Re: Rust in the kernel is no longer experimental

#150

Post by bonzini »

sayamqazi wrote: post #101
littlestymaar wrote: post #89

Earlier quoted context omitted.

IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel. Rust is different because it both: - significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities. - And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld. That doesn't mean Zig is a bad language…

Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??

You can absolutely write drivers with zero unsafe Rust. The bridge from Rust to C is where unsafe code lies.
Post reply on HN