The Rust for Linux project [LWN.net]

The Rust for Linux project

Posted Sep 18, 2021 0:06 UTC (Sat) by roc (subscriber, #30627)
In reply to: The Rust for Linux project by pbonzini
Parent article: The Rust for Linux project

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.

to post comments

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.