The Rust for Linux project [LWN.net]

The Rust for Linux project

Posted Sep 17, 2021 16:42 UTC (Fri) by pbonzini (subscriber, #60935)
In reply to: The Rust for Linux project by moltonel
Parent article: The Rust for Linux project

It's not about the correctness, it's the complexity. For me reviewing Rust means constantly asking myself "is this the right way to do it, or will it become excessive complexity and technical debt in the future". For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt, and sometimes I'm not sure which one is worse.

Almost every time I wrote complex code in Rust, I ended up throwing away the first version because I went down the wrong way to define types, establish ownership policies, pick what was hardcoded vs. what was abstracted. And it took a while to realize that, possibly only after using the library in anger. That is what I found even worse in Rust than in C++.

to post comments

The Rust for Linux project

Posted Sep 17, 2021 23:39 UTC (Fri) by st33med (guest, #144794) [Link]

It took me a bit to realize what you were getting at with 'technical debt' but I think I get it. If I understand you correctly, you're worried that the increased features adds to the complexity and thus costs later on to develop on top of a Rust library or rewrite it.

In C, I would argue many things are presented as 'overly simplified' with hidden behaviors that many developers may not consider until it bites you with undefined behavior. The typing system is not very strict which gives many footguns, there's practically no such thing as memory safety, etc. I think you know all this, and you're right that Rust adds features to be safe, and programming under Rust with this subset takes some time to think about how you want a program to function.

What I'm getting at is that it takes time and experience with Rust to be able to formulate an effective and friendly program structure, just like many other programming languages. You wouldn't be expected to pick up Haskell and know exactly the 'right' way to make a web server application, and Rust is no different. There's also never one obvious way to construct a program; sometimes you do need to scrap your current code and start over, regardless of the language used, and that happens less as you learn about the tools you are using.

The additional features of Rust do add more to consider in your design and may add to technical debt later on, but with experience, you gain insight into how your program synergizes with the Rust model and it becomes less of a burden. Likewise, the clearly marked unsafe portions of code, enforced typing model, and lack of undefined behavior remove a lot of time reviewing code and running static checkers against your program, of which C++ does not really remove despite being more 'feature-rich' than C and containing things like templates that Rust doesn't have.

The Rust for Linux project

Posted Sep 18, 2021 0:06 UTC (Sat) by roc (subscriber, #30627) [Link] (2 responses)

TBH I find this considerably worse in C++, because there are a lot more possible ways to do things in C++.

Seems to me your concern applies mainly to green-field development in Rust. Actual *maintenance* presents these questions less often, and when it does the solutions will be constrained by the patterns already set up.

But it would be interesting to collect more specific examples and see what can be done to provide guidance. I personally don't feel this burden myself. Maybe it's because I've been writing Rust code for five years, but even when I look at the code I wrote in the first year I think the design generally holds up.

The Rust for Linux project

Posted Sep 18, 2021 3:52 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (1 responses)

I tihnk this might apply more when Rust is brought into well-established codebases, that already have a certain complexity (both essential and accidental) baked in. Idiomatic Rust bindings pile more complexity on top.

The Rust for Linux project

Posted Sep 18, 2021 9:00 UTC (Sat) by laarmen (subscriber, #63948) [Link]

IMO this comes mostly from the fact that the bindings expose in a formal way some assumptions that are only informally known in the C codebase. I agree those are *really* painful to read and review (as they are to write...).

However, I often find pure Rust code patches easier to review than pure C patches, assuming knowledge of the underlying code base, as Rust allows for stronger local reasoning. If the patch introduces a call looking like foo(&my_struct), Rust tells me that the contents of my_struct won't change (barring interior mutability) whereas, seeing the exact same call in C, I'll need to know the particulars of foo() in order to judge the soundness of further use of my_struct.

The Rust for Linux project

Posted Sep 20, 2021 15:17 UTC (Mon) by moltonel (subscriber, #45207) [Link]

> For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt

I understand the fear, but it doesn't match my experience.

First the most obvious: paying technical debt (aka refactoring) is easier in Rust, because an API change will be noticed by the compiler in all callers, whereas in C many would be wrongly ignored. I rarely get the "needs a refactor but I'm too afraid to break things so I'll leave it" feeling with Rust.

Second, Rust helps making APIs that are harder to misuse, actively fighting technical debt. That's what you encountered when you realized you needed to throw away your first version(s). You probably should throw away your first C version too, but the compiler and base APIs don't tell you that. In a way, rustc is your first reviewer, making the human reviewer's job simpler. It might cause some anger when you're still learning that API or Rust itself, but it seems worth it.

The Rust for Linux project

Posted Sep 23, 2021 4:54 UTC (Thu) by marcH (subscriber, #57642) [Link]

> For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt, and sometimes I'm not sure which one is worse.

Define "worse", on which axis?

Debugging undefined behaviors and race conditions or refactoring existing code? I have my preference...