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

711–720 of 853 posts

Re: Rust in the kernel is no longer experimental

#711

Post by littlestymaar »

menaerus wrote: post #675
Xylakant wrote: post #673

Earlier quoted context omitted.

1 memory safety vulnerability, that's a pretty important distinction. Yes, I believe that at least the order of magnitude is correct because 4 800 000 of those lines are guaranteed to not have any by virtue of the compiler enforcing memory safety. So it's 1 per 200 000, which is 1-2 orders of magnitude worse, but still pretty darn good. Given that not all unsafe code actually has potential for memory safety issues an…

1 per 5M or 1 per 200K is pretty much unbelievable, especially in such a complex codebase, so all I can say then is to each their own.

> especially in such a complex codebase

You accidentally put the finger on the key point, emphasis mine.

When you have a memory-unsafe language, the complexity of the whole codebase impact your ability to uphold memory-related invariants.

But unsafe block are, by definition, limited in scope and assuming you design your codebase properly, they shouldn't interact with other unsafe blocks in a different module. So the complexity related to one unsafe block is in fact contained to his own module, and doesn't spread outside. And that makes everything much more tractable since you never have to reason about the whole codebase, but only about a limited scope everytime.

Re: Rust in the kernel is no longer experimental

#712

Post by kevin_thibedeau »

torginus wrote: post #631
jcranmer wrote: post #70

Earlier quoted context omitted.

There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every p…

I'd say, that even more than pointer sizes, the idea that a pointer is just a number really needs to die, and is in no way a forward looking decision expected of a modern language. Pointers should at no point be converted into numbers and back as that trips up many assumptions (special runtimes, static/dynamic analysis tools, compiler optimizations). Additionally, I would make it a priority that writing FFIs should b…

C doesn't require convertibility to an integer and recognizes that pointers may have atypical representations. Casting to integer types has always been implementation defined. [u]intptr_t is optional specifically to allow such platforms to claim standard conformance.

Re: Rust in the kernel is no longer experimental

#714

Post by Xylakant »

littlestymaar wrote: post #711
menaerus wrote: post #675

Earlier quoted context omitted.

1 per 5M or 1 per 200K is pretty much unbelievable, especially in such a complex codebase, so all I can say then is to each their own.

> especially in such a complex codebase You accidentally put the finger on the key point, emphasis mine. When you have a memory-unsafe language, the complexity of the whole codebase impact your ability to uphold memory-related invariants. But unsafe block are, by definition, limited in scope and assuming you design your codebase properly, they shouldn't interact with other unsafe blocks in a different module. So the…

That's the other interesting observation you can draw from that report. The numbers contained in the first parts about review times, rollback rates, etc. are broken down by change size. And the gap widens for larger changes. This indicates that Rusts language features support reasoning about complex changesets.

It's not obviously clear to me which features are the relevant ones, but my general observation is that lifetimes, unsafe blocks, the borrow checker allow people to reason about code in smaller chunks. For example knowing that there's only one place where a variable may be mutated supports understanding that at the same time, no other code location may change it.

Re: Rust in the kernel is no longer experimental

#715

Post by Xylakant »

menaerus wrote: post #707
aw1621107 wrote: post #689

Earlier quoted context omitted.

> which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". Strictly speaking, that encapsulation enables local reasoning about safety invariants does not necessarily imply that encapsulation guarantees local reasoning about safety invariants. It's always possible to write s…

Yes, but my point is when things blow up how exactly do you know which unsafe block you should look into? From their statement it appears as if there's such a simple correlation between "here's your segfault" and "here's your unsafe block that caused it", and which I believe there isn't, and which is why I said there's no encapsulation, local reasoning etc.

But you know that it's one of them. That cuts 96% of their codebase out, even assuming you have no idea which one it could be.

Re: Rust in the kernel is no longer experimental

#716

Post by division_by_0 »

josephg wrote: post #429
mlindner wrote: post #383

Earlier quoted context omitted.

I've never met anything written in JS/Typescript that I would call "well written".

I have. I personally really enjoy the recent crop of UI frameworks built for the web. Tools like Solidjs or Svelte. Whatever your thoughts are about react, the JavaScript community that has been the tip of the spear for experimenting with new ways to program user interfaces. They’ve been at it for decades - ever since jQuery. The rest of the programming world are playing catchup. For example, SwiftUI. VSCode is also…

Great points! I think your point about the JS community is often overlooked. Electron et al have made desktop UI/UX considerations more salient in the JS world. Desktop-like experiences in the browser can be great.

Re: Rust in the kernel is no longer experimental

#717

Post by dwattttt »

ACCount37 wrote: post #494
pornel wrote: post #332

Earlier quoted context omitted.

There's always someone willing to write COBOL for the right premium. I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).

Writing C++ is easier than writing Rust. But writing safe multithreaded code in C++? I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.

Anecdotally, my "wow, this Rust business might really go somewhere" moment was when I tried adding multithreading to a random tool I made (dispatching tasks to new threads).

Multithreading had not been planned or architected for, it took 30 min, included the compiler informing me I couldn't share a hashmap with those threads unsynchronised, and informing me on how to fix it.

Re: Rust in the kernel is no longer experimental

#718

Post by mustache_kimono »

AceJohnny2 wrote: post #166
mustache_kimono wrote: post #138

Earlier quoted context omitted.

> C will continue to be used because it always has been and always will be available everywhere Yes, you can use it everywhere. Is that what you consider a success?

... yes?

>> Yes, you can use it everywhere. Is that what you consider a success?

> ... yes?

Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.

Re: Rust in the kernel is no longer experimental

#719

Post by Ygg2 »

NetMageSCW wrote: post #667
Ygg2 wrote: post #327

Earlier quoted context omitted.

It removes a class of security vulnerabilities, modulo any unsound unsafe (in compiler, std/core and added dependency). In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action. As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident.…

“by removing the nastiest class of security vulnerabilities” and “reduce the likelihood” don’t seem to be in the same neighborhood.

In theory they are the same statement; in practice there is 0.01% chance someone wrote unsound code.

Re: Rust in the kernel is no longer experimental

#720

Post by dwattttt »

torginus wrote: post #633
accelbred wrote: post #628

Earlier quoted context omitted.

Lack of stable build-std and panic_immediate_abort features result in a order of magnitude size difference for some rust code I have. Using no_std brings it to ~60kb from ~350kb, but still more than the ~40kb for the C version

Afaik despite Rust not having exceptions, panic still unwinds the stack and executes 'drop'-s the same way C++ does, which means the code retains much of the machinery necessary to support exceptions.

The panic_immediate_abort feature should prevent this. build-std is the name of the feature that recompiles the Rust standard libraries with your chosen profile, so the combination of these two features should result in no unwinding code bloat.
Post reply on HN