Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

[ultimA]

I'm arguing: if you want safe code, don't use unsafe. Nothing more, nothing less.

Yes, now go and tell this kernel developers. Or to Mozilla. Or to all crate developers who have already committed this "crime" numerous times. What you are saying is irrealistic and oblivious to practice and reality. Unsafe code does get written a lot and it must be. And in turn many Rust projects end up being riddled with memory-safety issues like other projects.

[ultimA]

And in turn many Rust projects end up being riddled with memory-safety issues like other projects.

Now don't mistake me. I'm not saying this is the destiny of all Rust projects. Of course it is possible to write Rust code which is completely safe. Projects that are nicely self-contained, don't have to interact with anything, are not safety-critical, are not performance-critical... whether a specific project, like the Linux kernel, checks these criteria, is another question.

But writing completely safe code under certain conditions by following certain coding standards is nothing alien to a whole lot of other programming languages either.

[moltonel]

It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)

Agreed, FSVO "popular". There doesn't seem to be any shortage of people wanting to contribute Linux-in-Rust work, but they'll remain outnumbered by Linux-in-C developers in the foreseeable future, How much of a problem that'll be remains to be seen, and will certainly depend on the various subsystem maintainers' policies.

For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
(personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

Disagree, this doesn't work for C++ either. C++ has its own set of gotchas, it's not just API-level differences you can look up in a reference. If anything, the fact that Rust doesn't look like C makes it a better candidate than C++ because it'll avoid overconfident C developers thinking they can write good C++.

At $DAYJOB I mentor new recruits on both large C++ and Rust projects, and I have less trouble accepting Rust merge requests than C++ ones. Rust usually has tighter APIs, enabling devs to reason more locally without having to check foreign code or manually uphold invariants as much as C++. Rust is ultimately a simpler language than C++ (Rust's initial learning curve is notoriously steep, but C++'s learning curve keeps climbing for years), making training less costly.

[moltonel]

writing completely safe code under certain conditions by following certain coding standards is nothing alien to a whole lot of other programming languages either.

Absolutely. The debate is over what those conditions are, and how costly they are to implement. Seasoned C++ devs seem particularly prone to underestimating the later.

[oleid]

Yes, now go and tell this kernel developers. Or to Mozilla. Or to all crate developers who have already committed this "crime" numerous times. What you are saying is irrealistic and oblivious to practice and reality. Unsafe code does get written a lot and it must be.

True, but usually you can contain it and know exactly where to look for

[ShFil]

@NobodyXu @moltonel
as I written earlier I don't think c++ on its own is good solution. Somehow c++ is still missing option to disable features, for example compilers sees `std::thread` or raw copy constructor then it stops compilation. Also approach to undefined behavior, "it cannot happen so let's optimize" not so often is bad.

Maybe I shouldn't have used c++ as comparison point. Yeah, c++ is tricky and it's super easy for c developer to make a bug, (wanted to point that some smaller fixes can be checked by c developer).

[ultimA]

Idiomatic Rust code typically uses unsafe in the following cases

1. C FFI , in which case if you get a memory leak its actually because of C not Rust
2. Memory mapped IO/hardware interfaces

So I am sorry but you are spreading grade A bullshit, because if there are "memory safety issues" in typical Rust code, you know its because of some underlying C library or because you are interfacing the hardware. What you do know is that the 70-100% of the rest of your code is memory safe, unlike the 0% you have with C (unless you are using one of those formally verified C subsets with a theorem prover).

I never compared Rust to C. I agree 100%, C is ridiculously bad in this aspect. However, the memory-safety difference between idiomatic Rust and idiomatic C++ is minimal, while both being easy to develop for. Mind you, idiomatic C++ code is not the same today as it was 10 years ago (not even sure if "idiomatic C++" existed 10 years ago - today it does). People who think everything needs to be rewritten in Rust and that will bring us salvation are wrong on two fronts: 1) it won't, and 2) easy memory-safe programming existed even before Rust. Not in C, that is true.

[Vistaus]

But if it is 20% Rust, I do expect it to have almost 20% (or at least 10%) less memory-related issues, which is not the case at all.

That's not how math works.

[Vistaus]

Imho there are several issues with rust:
- It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)
- For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
- (personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

What slow release cycle? I receive kernel .x updates very frequently.

Also, if C maintainers are so easy to find, why don't you go and tell the SystemD folks? 'Cause they claim it's hard to find C maintainers, but clearly that's a bad excuse 'cause *you* can just pull them out of a can, right?

[oleid]

However, the memory-safety difference between idiomatic Rust and idiomatic C++ is minimal, while both being easy to develop for.

with idiomatic rust code you mean 'restricting to safe rust?
Considering C++ - no, C++ is not as safe. Not even if you only use modern C++17 code. I program c++ as a day job for many years and I think I know what I'm talking about as I know rust as well.

To sum up my two biggest concerns:

* C++ won't stop you from reading memory from Thread A while writing from Thread B. rust does, at compile time.
* C++ won't stop you from using references, which became invalid.

And the worst part is: neither the compiler nor clang-tidy will complain.

Now you could argue: well, that stuff is easy to get right in the first place. I agree, most of the time people do. But what happens if after some time people refactor, the behaviour changes and now you have another thread and forgot to add mutexes or mutate some container while keeping the reference? Bam, crash!

Rust wouldn't compile the refactored code, that's an advantage.