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

381–390 of 853 posts

Re: Rust in the kernel is no longer experimental

#381

Post by menaerus »

baq wrote: post #328
menaerus wrote: post #316

Earlier quoted context omitted.

Sorry but what have I said wrong? The nature of code written in kernel development is such that using unsafe is inevitable. Low-level code with memory juggling and patterns that you usually don't find in application code. And yes, I have had a look into the examples - maybe one or two years there was a significant patch submitted to the kernel and number of unsafe sections made me realize at that moment that Rust, in…

> I am not sure what point did you try to make by giving something that is not even a production quality code? let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms. > Sorry, I am not buying that argument. here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% - and you're trying to sell it as a bad thing, wh…

> let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms.

I don't know what one should even make from that statement.

> here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10%

It's more than 10%, you didn't even bother to look at the code but still presented it, what in reality is a toy driver example, as something credible (?) to support your argument of me spreading FUD. Kinda silly.

Even if it was only that much (10%), the fact it is in the most crucial part of the code makes the argument around Rust safety moot. I am sure you heard of 90/10 rule.

The time will tell but I am not holding my breath. I think this is a bad thing for Linux kernel development.

Re: Rust in the kernel is no longer experimental

#382

Post by gjajric3 »

debugnik wrote: post #366
gjajric2 wrote: post #336

Earlier quoted context omitted.

[flagged]

Okay I had upvoted you but now you're just being an asshole. Predictable from someone on multiple fucking throwaways created just to answer on a single post and crap on a piece of tech I suppose; I don't even care much about Rust. And I'm sorry to inform you I'm not Klabnik, but delusions are free: Maybe you think everyone using -nik is actually the same person and you've uncovered a conspiracy. Congrats on that. I'd…

[flagged]

Re: Rust in the kernel is no longer experimental

#383

Post by mlindner »

recursive wrote: post #50
bogantech wrote: post #8

Earlier quoted context omitted.

Most software development these days is JS/Typescript slop, popular doesn't equal better

You can write slop in any language. And good software for that matter.

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

Re: Rust in the kernel is no longer experimental

#384

Post by gf000 »

dwattttt wrote: post #182
tomnipotent wrote: post #162

Earlier quoted context omitted.

I'm unaware of any such marketing.

Zig does claim that it > ... 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".

Runtime checks can only validate code paths taken, though. Also, C sanitizers are quite good as well nowadays.

Re: Rust in the kernel is no longer experimental

#385

Post by MobiusHorizons »

vlovich123 wrote: post #99
MobiusHorizons wrote: post #34

Earlier quoted context omitted.

It's mostly embedded / microcontroller stuff. Things that you would use something like SDCC or a vendor toolchain for. Things like the 8051, stm8, PIC or oddball things like the 4 cent Padauk micros everyone was raving about a few years ago. 8051 especially still seems to come up from time to time in things like the ch554 usb controller, or some NRF 2.4ghz wireless chips.

Those don’t really support C in any real stretch, talking about general experience with microcontrollers and closed vendor toolchains; it’s a frozen dialect of C from decades ago which isn’t what people think of when they say C (usually people mean at least the 26 year old C99 standard but these often at best support C89 or even come with their own limitations)

It’s still C though, and rust is not an option. What else would you call it? Lots of c libraries for embedded target C89 syntax for exactly these reasons. Also for what it’s worth, SDCC seems to support very modern versions of C (up to C23), so I also don’t think that critique is very valid for the 8051 or stm8. I would argue that c was built with targets like this in mind and it is where many of its quirks that seem so anachronistic today come from (for example int being different sizes on different targets)

Re: Rust in the kernel is no longer experimental

#386

Post by mlindner »

dralley wrote: post #45
wewewedxfgdf wrote: post #42

Oh dear can you imagine the crushing complexity of a future Rust kernel.

By most accounts the Rust4Linux project has made the kernel less complex by forcing some technical debt to be addressed and bad APIs to be improved.

This made me quite curious, is there a list somewhere of what bad APIs have been removed/improved and/or technical debt that's been addressed? Or if not a list, some notable examples?

Re: Rust in the kernel is no longer experimental

#387

Post by rustoleum69 »

weinzierl wrote: post #271

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no goin…

[flagged]

Re: Rust in the kernel is no longer experimental

#388

Post by TazeTSchnitzel »

rustoleum69 wrote: post #387
weinzierl wrote: post #271

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no goin…

[flagged]

Because someday the programming state of the art must advance beyond 1970, and someday we must stop introducing new memory safety bugs that cause horrific vulnerabilities, and for kernel code we don't have the luxury of recompiling everything with garbage collection turned on as a band-aid for C's incurable defects.

Re: Rust in the kernel is no longer experimental

#390

Post by debugnik »

gjajric3 wrote: post #382
debugnik wrote: post #366

Earlier quoted context omitted.

Okay I had upvoted you but now you're just being an asshole. Predictable from someone on multiple fucking throwaways created just to answer on a single post and crap on a piece of tech I suppose; I don't even care much about Rust. And I'm sorry to inform you I'm not Klabnik, but delusions are free: Maybe you think everyone using -nik is actually the same person and you've uncovered a conspiracy. Congrats on that. I'd…

[flagged]

Giving you the benefit of the doubt at first was completely wrong, that much I agree.
Post reply on HN