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

621–630 of 853 posts

Re: Rust in the kernel is no longer experimental

#621

Post by accelbred »

Levitating wrote: post #549
jenadine wrote: post #183

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not 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)

> Not 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) It's trivial to install a specific version of the toolchain though.

It really isn't if bootstrapping from source.

Re: Rust in the kernel is no longer experimental

#622

Post by pessimizer »

School-Cotton wrote: post #581
bayindirh wrote: post #476

Earlier quoted context omitted.

Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion. I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first a…

LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction. Open source and free software mean almost exactly the same set of software; the only difference between the two terms, according to RMS and other free software advocates, is the emphasis . Sort of like the difference between the Gulf of America and…

This is nonsense, and I have no idea why you need to believe it.

Open Source can be used as Free Software because Open Source can be used as proprietary software or anything else, as long as you include the license or mention the author somewhere or whatever. But these are both standards for actual licenses, and the actual licenses are different. Copyleft software can not be included in your proprietary software.

Copyleft software is restrictive. You are required to allow people to access it, and required to redistribute it in source form if you are redistributing it in compiled form (or over the network for modern copyleft licenses.) You are also required to include all of the changes that you have made to the things that you have compiled within that source distribution, and to also distribute other code that is required to to make your software package work under the same licensing.

The confusion is only in people spreading misinformation trying to confuse the two things. You clearly seem to know that RMS can prefer copyleft over permissive licenses, but still need to pretend that there's no difference between the two. If you know that someone can prefer white chocolate to dark chocolate, there's obviously something wrong with you if you in the same breath say that there is no difference between white chocolate and dark chocolate. Why deceive people? What's the point?

If they're all exactly the same, everybody should be using the GPL in Linux then. Shouldn't even be a thought. Why waste time forcing corporate-friendly licenses if it doesn't matter and some people are against them? Shouldn't parsimony rule then?

Re: Rust in the kernel is no longer experimental

#623

Post by menaerus »

kaoD wrote: post #531
menaerus wrote: post #434

Earlier quoted context omitted.

So, unsafe block every 70 LoC in 1500 LoC toy example? Sure, it's a strong argument.

How is that worse than everything being unsafe? I've seen this argument thrown around often here in HN ( "$IMPROVEMENT is still not perfect! So let's keep the statu quo." ) and it baffles me. C is not perfect and it still replaced ASM in 99% of its use cases.

No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust.

Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.

Re: Rust in the kernel is no longer experimental

#624

Post by estebank »

steveklabnik wrote: post #597
estebank wrote: post #576

Earlier quoted context omitted.

> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp. Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?

For what it’s worth, I perceived hostility here a long time ago, but those people have pretty explicitly come around since. That said I also think the parent is just wrong to focus on gcc vs llvm as the source of that, and also to bring it up at this point regardless.

The only thing I could ever see misconstrued of as "hostility" with my earshot from anyone in t-compiler is myself saying something along the lines of "that sounds like a lot of effort that doesn't gain much over rustc_codegen_gcc, and I am not interested in contributing to a cpp codebase". Note that nowhere in my position I state anything like "this shouldn't exist" or "they should stop" or "we shouldn't cooperate". If anything, the communication channels with them are quite open and friendly. During the RustNL Q&A for the gccrs talk people from t-lang and t-compiler asked point blank "what can we do to help make your life easier". Beyond some minor concerns about the potential for language divergence and gccisms becoming a thing, which they have been very vocal about wanting to avoid, my opinion on the project is that it is net positive and I am impressed with them, and I'll help in any way I can, short of writing code on my spare free time for yet another rust compiler—one is a handful already for me :)

Re: Rust in the kernel is no longer experimental

#625

Post by mustache_kimono »

mrweasel wrote: post #242
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?

I'm curious as to which other metric you'd use to define successful? If it actual usage, C still wins. Number of new lines pushed into production each year, or new project started, C is still high up the list, would be my guess. Languages like Rust a probably more successful in terms of age vs. adoption speed. There's just a good number of platforms which aren't even supported, and where you have no other choice than…

> I'm curious as to which other metric you'd use to define successful? If it actual usage, C still wins.

Wait, wait, you can use C everywhere, but if absolute lines of code is the metric, people seem to move away from C as quickly as possible (read: don't use C) to higher level languages that clearly aren't as portable (Ruby, Python, Java, C#, C++, etc.)?

> Rust can't target most platforms, and it compiles on even less. Unless Linux want's to drop support for a good number of platforms, Rust adoption can only go so far.

Re: embedded, this is just terribly short sighted. Right now, yes, C obviously has the broadest possible support. But non-experimental Linux support starts today. GCC is still working on Rust support and rust_codegen_gcc is making in roads. And one can still build new LLVM targets. I'd be interested to hear what non-legacy platforms actually aren't supported right now.

But the real issue is that C has no adoption curve. It only has ground to lose. Meanwhile Rust is, relatively, a delight to use, and offers important benefits. As I said elsewhere: "Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?" The future looks bright for Rust, if you believe as I do, we are beginning to demand much more from our embedded parts.

Now, will Rust ever dominate embedded? Will it be used absolutely everywhere? Perhaps not. Does that matter? Not AFAIAC. Winning by my lights is -- using this nice thing rather than this not so nice thing. It's doing interesting things where one couldn't previously. It's a few more delighted developers.

I'd much rather people were delighted/excited about a tech/a language/a business/a vibrant community, than, whatever it is, simply persisted. Because "simply persisted", like your comment above, is only a measure of where we are right now.

Another way to think of this is -- Perl is also everywhere. Shipped with every Linux distro and MacOS, probably to be found somewhere deep inside Windows too. Now, is Perl, right now, a healthy community or does it simply persist? Is its persistence a source of happiness or dread?

Re: Rust in the kernel is no longer experimental

#626

Post by sophacles »

archargelod wrote: post #481
drnick1 wrote: post #14

Earlier quoted context omitted.

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work acros…

Perhaps we can finally stop defining abis in terms of c structs!

Re: Rust in the kernel is no longer experimental

#627

Post by zozbot234 »

kbolino wrote: post #607
zozbot234 wrote: post #582

Earlier quoted context omitted.

AIUI, this particular change would only impact some newly supported architectures going forward. These don't need to be buildable with older editions.

This feels antithetical to two of the main goals of editions. One of those goals is that code which was written for an older edition will continue to work. You should never be forced to upgrade editions, especially if you have a large codebase which would require significant modifications. The other goal is that editions are interoperable, i.e. that code written for one edition can rely on code written for a differen…

If the part about how "most of those crates wouldn't be doing funny operations on pointers" can be verified automatically in a way that preserves safety guarantees when usize != uaddr/uptr, these crates can continue to build without transitioning to a newer edition. Otherwise, upgrading these crates is the right move. Other code targeting earlier editions of Rust would still build, they would simply need a compiler version update when depending on the newly-upgraded crates.

Re: Rust in the kernel is no longer experimental

#628

Post by accelbred »

QuiEgo wrote: post #68
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?

Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.

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

Re: Rust in the kernel is no longer experimental

#629

Post by xphos »

CursedSilicon wrote: post #614
iurbwdj wrote: post #394

Earlier quoted context omitted.

It involved large parts of the Rust community, and the famous Rust developer Hector Martin (with an alter ego of Asahi Lina, a female vtuber, which he appears irrationally embarrassed about), harassing others. Even Linus Torvalds called out Hector Martin. https://lkml.org/lkml/2025/2/6/1292 > On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote: > > If shaming on social media does not work, then tell me what does, becaus…

Is there any evidence "Asahi Lina" is Hector?

Isn't Asahi Lina Married to some other japanese Vtubber now? I mean maybe you'd fake all that but I doubt it. Both are more likely real people who are different. The people have totally different eccentricties its really hard to fake that type difference for a long time.

[source] https://x.com/Lina_Hoshino/status/1862840998897861007

Re: Rust in the kernel is no longer experimental

#630

Post by uplifter »

School-Cotton wrote: post #581
bayindirh wrote: post #476

Earlier quoted context omitted.

Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion. I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first a…

LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction. Open source and free software mean almost exactly the same set of software; the only difference between the two terms, according to RMS and other free software advocates, is the emphasis . Sort of like the difference between the Gulf of America and…

At least concerning Richard M. Stallman's take on this subject, this characterization is completely wrong.

RMS certainly does not consider the difference between open source and free software to be merely one of 'emphasis.' According to him they are completely different animals. Here are his words on their difference[0]:

> 'When we call software “free,” we mean it respects the users’ essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes (see http://www.gnu.org/philosophy/free-sw.html). This is a matter of freedom, not price, so think of “free speech,” not “free beer.” ... Nearly all open source software is free software; the two terms describe almost the same category of software. But they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. For the free software movement, free soft- ware is an ethical imperative, because only free software respects the users’ freedom. By contrast, the philosophy of open source considers issues in terms of how to make software “better”—in a practical sense only. It says that non-free software is a suboptimal solution. For the free software movement, however, non-free software [including non-free open source software] is a social problem, and moving to free software is the solution.'

[emphasis and square brackets mine]

It's not that RMS 'prefers the term "free software" over "open source"' but that he prefer software be free instead of non-free. The source being open is just an incomplete precondition for being free.

[0] https://courses.cs.duke.edu/common/compsci092/papers/open/st...

Post reply on HN