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

701–710 of 853 posts

Re: Rust in the kernel is no longer experimental

#701

Post by dralley »

mewse-hn wrote: post #583
bpavuk wrote: post #340

Earlier quoted context omitted.

I am missing some context, did not follow the Linux/Rust drama. which guy?

Ted T'so: "Here’s the thing: you’re not going to force all of us to learn Rust." https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-r... https://youtu.be/WiPp9YEBV0Q?t=1529

Ted was being an asshole, nobody was asking him to learn Rust, he completely misinterpreted the point being made and then proceeded to go on an angry rant for like 5 minutes in the middle of a presentation which just is kind of disrespectful.

Re: Rust in the kernel is no longer experimental

#702

Post by dralley »

xphos wrote: post #635
teekert wrote: post #459

Earlier quoted context omitted.

I can't find the movie, but there was a guy angry that stated that he should not have to learn Rust, nobody should. And Rust should not be in the kernel.

Its in a talk about File systems in Rust for Linux. Basically the rust maintainer who I think stepped down was talking about how the C-code base for VFS has a lot of documented but complex orderings where you have to call a lock, or pin before accessing an Inode(or something) one way but not the other. They made a bunch of Rust Types so you basically could not produce an illegal ordering and got heckled pretty hard b…

IIRC, the point was actually that they were undocumented in many cases, and that the Rust developers were willing to take on a lot of work, but they would need help with understanding all of the hidden and implicit "rules", but that they had received pushback for simply asking questions or asking for documentation to be comprehensive.

Re: Rust in the kernel is no longer experimental

#703

Post by mustache_kimono »

NetMageSCW wrote: post #671
mustache_kimono wrote: post #625

Earlier quoted context omitted.

> 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 l…

Why do you think people are delighted/excited about Rust? Some people are, but I’m sure plenty of people are about C and Perl is well. Some people isn’t most people and certainly not all people.

> Some people isn’t most people and certainly not all people.

I never said Rust was the universal language, that is pleasing to all people. I was very careful to frame Rust's success in existential, not absolute or universal, terms:

>> 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 am not saying these technologies (C and Perl) should go away. I am saying -- I am very pleased there is no longer a monoculture. For me, winning is having alternatives to C in embedded and kernel development, and Perl for scripting, especially as these communities, right now, seem less vibrant, and less adaptable to change.

Re: Rust in the kernel is no longer experimental

#704

Post by nikanj »

jacquesm wrote: post #510
acdha wrote: post #491

Earlier quoted context omitted.

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to suppo…

There was a time when it came to 64 bit support Alpha really was the only game in town where you could buy a server without adding a sixth zero to the bill. It was AMD, not Itanium that killed Alpha.

AMD, and the addition of PAE to the Pentium Pro which allowed 32-bit systems to reasonably have huge (for that time) amounts of memory

Re: Rust in the kernel is no longer experimental

#705

Post by kbolino »

aw1621107 wrote: post #690
kbolino wrote: post #547

Earlier quoted context omitted.

Great info! Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance. I think the answer to "can this be solved with editions"…

> Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance. Provenance-related work seems to be progressing at a decent pace,…

Indeed, the only missing piece really then is the ability to warn/error when exposed provenance and/or as-casts are used.

Re: Rust in the kernel is no longer experimental

#706

Post by veidelis »

dxroshan wrote: post #346
veidelis wrote: post #184

Earlier quoted context omitted.

Is rust code part of user space?

Projects like GNOME are increasingly using Rust.

From kernel side, I meant - I wasn't clear. Now I understand what's the meaning of "don't break rust code". Happy that rust's journey in the kernel is successful so far. The pace seems strong.

Re: Rust in the kernel is no longer experimental

#707

Post by menaerus »

aw1621107 wrote: post #689
menaerus wrote: post #668

Earlier quoted context omitted.

They also say The practice of encapsulation enables local reasoning about safety invariants. 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". This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obviou…

> 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.

Re: Rust in the kernel is no longer experimental

#708

Post by dwattttt »

timow1337 wrote: post #350
thayne wrote: post #30

Earlier quoted context omitted.

> very slow compilation times That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.

Compared to C, rust compiles much slower. This might not matter on performant systems, but when resources are constrained you definitely notice it. And if the whole world is rewritten in Rust, this will have a non-significant impact on the total build time of a bunch of projects.

It's been mentioned obliquely, but what's considered "part of the compilation process" is different between Rust and C.

Most of the examples of "this is what makes Rust compilation slow" are code generation related; for example, a Rust proc_macro making compilation slow would be equivalent to C building a code generator (for schemas? IDLs?), running it, then compiling the output along with its user.

Re: Rust in the kernel is no longer experimental

#709

Post by grimgrin »

GuB-42 wrote: post #592
grimgrin wrote: post #432

Earlier quoted context omitted.

linus torvalds

Linus Torvalds greenlit Rust in the kernel, and as a BDFL, he is the one to decide. He has no reason to be upset with any decision because ultimately, all decisions are his own. If he didn't want Rust in the kernel, he would have said it, and there would have been no Rust in the kernel. It is also the reason why there is no C++ in the kernel, Linus doesn't like C++. It is that simple. And I respect that, Linux is hug…

I only typed Linus Torvald not realizing the person was asking for a "movie character" quite literally, lol. I thought "you mean the guy famous for (among many things..) his behavior?"

This is the first time I've had a comment hit -3 which, I mean, I get it!!

Re: Rust in the kernel is no longer experimental

#710

Post by the_why_of_y »

uplifter wrote: post #630
School-Cotton wrote: post #581

Earlier quoted context omitted.

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 t…

> Open source and free software mean almost exactly the same set of software

> Nearly all open source software is free software; the two terms describe almost the same category of software.

I see no disagreement, how is GP "completely wrong"?

Post reply on HN