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

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

231–240 of 240 posts

Re: Upcoming Rust language features for kernel development

#231

Post by seabrookmx »

kachapopopow wrote: post #223
seabrookmx wrote: post #206

Earlier quoted context omitted.

I'm not sure if you're joking, but if not this is a fundamental misunderstanding of how Rust (and C) are used in the kernel. Much like how you don't have the C stdlib when writing kernel code, Rust is used with the no_std option. You do not use cargo and do not have access to crates. You'd likely have to rewrite half of tokio to use kernel level abstractions for things like sockets and everything else that interacts…

that's the joke. I've made most of c runtime work in the windows kernel before though.

Yeah that sounds a lot like nolibc which is basically a libc-ish shim that's in the Linux kernel tree.

Re: Upcoming Rust language features for kernel development

#232

Post by kstrauser »

vlovich123 wrote: post #229
kstrauser wrote: post #220

Earlier quoted context omitted.

Not to mention that `cargo clippy` runs in 200ms, making it far and away the fastest such thing I've used with any language. It's a lot easier to make your code clean when the checker runs nearly instantaneously.

And when you can pass —fix and the vast majority of suggestions are auto-applied

Truly, the cargo ecosystem is unbelievably ergonomic and delightful.

Re: Upcoming Rust language features for kernel development

#233

Post by uecker »

gpm wrote: post #142
uecker wrote: post #141

Earlier quoted context omitted.

I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still th…

> First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use? > Second, I do not even believe that memory safety is that important that this trumps other considerations In your previous comment you stated "a memory safe C would be far more useful. It is sad…

For example cyclone, checked C, safe-c, deputy etc.

I agree that memory safety is useful, but I think the bigger problem is complexity, and Rust goes in the wrong direction. I also think that any investment into safety features - even if not achieving perfect safety - in C tooling would have much higher return of investment and bigger impact on the open-source ecosystem.

Re: Upcoming Rust language features for kernel development

#234

Post by uecker »

Jweb_Guru wrote: post #169
gpm wrote: post #142

Earlier quoted context omitted.

> First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use? > Second, I do not even believe that memory safety is that important that this trumps other considerations In your previous comment you stated "a memory safe C would be far more useful. It is sad…

> Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use? They can't, of course, because there was no such language. Some people for whatever reason struggle to acknowledge that (1) Rust was not just the synthesis of existing ideas (the borrow checker was novel, and aspects of its thread safety story like Send and Sync were also AFAIK not found in the literatu…

I don't think there are many new ideas in Rust that did not exist previously in other languages. Lifetimes, non-aliasing pointers etc all certainly existed before. Rust is also only somewhat ready for industry use because suddenly some companies poured a lot of money in it. But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.

Re: Upcoming Rust language features for kernel development

#235

Post by Jweb_Guru »

uecker wrote: post #234
Jweb_Guru wrote: post #169

Earlier quoted context omitted.

> Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use? They can't, of course, because there was no such language. Some people for whatever reason struggle to acknowledge that (1) Rust was not just the synthesis of existing ideas (the borrow checker was novel, and aspects of its thread safety story like Send and Sync were also AFAIK not found in the literatu…

I don't think there are many new ideas in Rust that did not exist previously in other languages. Lifetimes, non-aliasing pointers etc all certainly existed before. Rust is also only somewhat ready for industry use because suddenly some companies poured a lot of money in it. But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.

"Lifetimes" didn't exist before. Region typing did, but it was not accompanied by a system like Rust's borrow checker, which is essential for actually creating a usable language. And we simply did not have the tooling required (e.g. step-indexed concurrent separation logic with higher order predicates) to prove a type system like that correct until around when Rust was released, either. Saying that this was a solved problem because Cyclone had region typing or because of MLKit, or people knew how to do ergonomic uniqueness types because of e.g. Clean, is the sort of disingenuous revisionist history I'm pushing back on.

> But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.

Like I said, they picked Rust because there was literally no other suitable language. You're avoiding actually naming one because you know this is true. Even among academic languages very few targeted being able to replace C++ everywhere directly as the language was deemed unsuitable for verification due to its complexity. People were much more focused on the idea of providing end to end verified proofs that C code matched its specification, but that is not a viable approach for a language intended to be used by regular industry programmers. Plenty of other research languages wanted to compete with C++ in specific domains where the problem fit a shape that made the safety problem more tractable, but they were not true general purpose languages and it was not clear how to extend them to become such (or whether the language designers even wanted to). Other languages might have thought they were targeting the C++ domain but made far too many performance sacrifices to be suitable candidates, or gave up on safety where the problem get hard (how many "full memory safety" solutions completely give up on data races for example? More than a few).

As a "C++ guy" Rust was the very first language that gave us what we actually wanted out of a language (zero performance compromises) while adding something meaningful that we couldn't do without it (full memory safety). Even where it fell short on performance or safety, the difference with other languages was that nobody said "well, you shouldn't care about that anyway because it's not that big a deal on modern CPUs" or "well, that's a stupid thing for a user to do, who cares about making that case safe?" The language designers genuinely wanted to see how far we cold push things without compromises (and still do). The work to allow even complex Linux kernel concurrent patterns (like RCU or sequence locking) to be exposed through safe APIs, without explicitly hardcoding the safety proofs for the difficult parts into the language, is just an extension of the attitude that's been there since the beginning.

Re: Upcoming Rust language features for kernel development

#236

Post by vacuity »

GeorgeTirebiter wrote: post #166
School-Cotton wrote: post #129

Earlier quoted context omitted.

Rust is more complex than C, yes, but as someone who has used both professionally, it is not even close to being as complex as C++. In fact it is closer in complexity to C than to C++.

Perhaps you can help guide a C expert but C++ avoider (and super-avoider of Rust, so far): If C is 1 in complexity, where does C++ and Rust fall. By 'complexity' here I mean: the ability to keep the Entire Language in your head at the same time. C, although it does have complex corners, is -- mostly -- not overly complicated. (As you can probably tell, I prefer assembly, because it is the least complicated. You can b…

Contrasting the sibling reply from umanwizard, I'll say Rust is 75, but 95% of the time, it's 40 or under. There's a pretty obvious cliff, so you can avoid or detect it unless you need to do something advanced. Unlike C++, you don't just "run into" the complexity unknowingly, as if it's hiding around every corner. Normal Rust is very well crafted such that all the gears turn together, but there are many rough edges (async, traits, lifetimes) that still need a lot of refinement. As the sibling reply says, I doubt you'll like Rust. I don't like Rust when it's in 75-complexity mode either, but I think Rust is a great example of an evolving language, and the complexity should decrease gradually. Moreover, Rust has/will inspire other languages that may be more palatable.

Re: Upcoming Rust language features for kernel development

#237

Post by vacuity »

Jweb_Guru wrote: post #235
uecker wrote: post #234

Earlier quoted context omitted.

I don't think there are many new ideas in Rust that did not exist previously in other languages. Lifetimes, non-aliasing pointers etc all certainly existed before. Rust is also only somewhat ready for industry use because suddenly some companies poured a lot of money in it. But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.

"Lifetimes" didn't exist before. Region typing did, but it was not accompanied by a system like Rust's borrow checker, which is essential for actually creating a usable language. And we simply did not have the tooling required (e.g. step-indexed concurrent separation logic with higher order predicates) to prove a type system like that correct until around when Rust was released, either. Saying that this was a solved…

Rust isn't perfect, but it's basically the most viable language currently to be used in software such as Linux. It's definitely more of a C++ contender than anything else, but manages to be very usable in most other cases too. Rust 1.0 got a lot of things right with its compile-time features, and the utility of these features for "low-level" code has been demonstrated repeatedly. If a language is to replace Rust in the future, I expect it will take on many of the strengths of Rust. Moreover, Rust is impressive at becoming better. The work for Rust-for-Linux, alongside various other improvements (e.g. next trait solver, Polonius and place-based borrowing, parallel rustc frontend) show that Rust can evolve significantly without a huge addition in complexity. Actually, most changes should reduce its complexity. Yes, Rust has fumbled some areas, such as the async ecosystem, the macro ecosystem, and pointer-width integers, but its mistakes are also considered for improvement. The only unfortunate thing is the lack of manpower to drive some of these improvements, but I'm in it for the long run. Frankly, I'd say that if the industry had to use only one language tomorrow, Rust is the best extant choice. Really, I'm open to

And, it's really funny that GP criticizes Rust but doesn't acknowledge that of course blood, sweat, and tears have already gone into less drastic variants for C or C++. Rust itself is one of the outputs of the solution space! Sure, hype is always a thing, but Rust has quite demonstrated its utility in the free market of programming languages. If Rust was not as promising as it is, I don't see why all of these companies and Linus Torvalds would seriously consider it after all these years of experience. I can accept if C had a valid "worse is better" merit to it. I think C++, if anything, has the worst value-to-hype ratio of any programming language. But Rust has never been a one-trick pony for memory safety, or a bag of old tricks. Like any good language, it offers its own way of doing things, and for many people, its way is a net improvement.

Re: Upcoming Rust language features for kernel development

#238

Post by Ericson2314 »

surajrmal wrote: post #226
Ericson2314 wrote: post #225

Gah, I've been waiting for &out (and &in) for so long, a decade now. Please, Rust devs, finally give up on the idea that they aren't needed and implement them.

Did you try writing an rfc proposal for them?

A wrote https://github.com/Ericson2314/rust-papers on that topic, and wrote RFCs on other, simpler, topics.

Re: Upcoming Rust language features for kernel development

#239

Post by shakow »

yencabulator wrote: post #211
ogoffart wrote: post #24

Earlier quoted context omitted.

Regarding Rust GUI framework, there is also Slint https://slint.dev (Disclaimer: I'm one of the Slint developers.)

Slint is not a great option: https://github.com/slint-ui/slint?tab=License-1-ov-file#read...

God forbid a company plays the GPL rules fair and square...

Re: Upcoming Rust language features for kernel development

#240

Post by yencabulator »

shakow wrote: post #239
yencabulator wrote: post #211

Earlier quoted context omitted.

Slint is not a great option: https://github.com/slint-ui/slint?tab=License-1-ov-file#read...

God forbid a company plays the GPL rules fair and square...

Even FSF makes their central libraries LGPL not GPL.
Post reply on HN