Mesa Developers Discuss The Possibility Of Rust Graphics Driver Code

[ed31337]

Yeah, and then when Mozilla implodes and takes down Rust with it, what then? Mesa developers will have to take up maintaining Rust in addition to Mesa?

[shmerl]

Keeping things as is for the time being is an argument I get. Moving to C++ instead of moving to Rust when they are already considering moving? That I don't get. And I'm saying it as a someone who likes C++ in general. But Rust is so much better!

Though reading through the comments, most actually agree there that Rust is a better option than C and C++. So outlook is positive in that thread.

[oleid]

The difficulty arises trying to have good compatibility between two higher level languages (C++ <> Rust). .

Isn't it simple? Do it like librsvg. Require a C API for the outside (i.e. driver/mesa internals) and be done.

But my vote is simply keep to homogenous C with everything and just AddressSanitize like hell. It gives a cleaner architecture overall.

Not really. It means you have to think less about architecture.

[kpedersen]

That's disingenuous. Firstly Mesa barely has any C++ code.
And Rust was pretty much designed to have good compatibility with C code due to most of Mozilla's code being written in C.
The point is that the code that ends up written in Rust, has a reduced attack surface (even if other attack surfaces still exist), having low attach surface drivers is has been important for like 10 years but little has been done in that direction and this would be a big step.

I'm not really talking about having good compatibility with C code. That is "easy" because C is so flexible and simple to work with. The difficulty arises trying to have good compatibility between two higher level languages (C++ <> Rust). That is much harder and Rust doesn't do anything particularly magical here. Having a lot of Rust (or C++) in Mesa will block any newer high level languages in future.

I don't disagree that Rust is safer than C and C++ (and certainly *much* safer than how many developers use C++). But my vote is simply keep to homogenous C with everything and just AddressSanitize like hell. It gives a cleaner architecture overall.

[cb88]

Adding a high(er) level language like C++ or Rust causes issues when interfacing with it from any other languages. You provided a very good example why both C++ *and* Rust should be kept out of a number of underlying codebases.

Mesa already has C++ in it so in many cases you would need to go C++ <> C <> Rust to communicate between them. This is messy, fragile, wasteful of resources and will likely also undermine many of Rust's interesting safety mechanisms anyway.

That's disingenuous. Firstly Mesa barely has any C++ code.
And Rust was pretty much designed to have good compatibility with C code due to most of Mozilla's code being written in C.
The point is that the code that ends up written in Rust, has a reduced attack surface (even if other attack surfaces still exist), having low attack surface drivers is has been important for like 10 years but little has been done in that direction and this would be a big step.

[TheOne]

In my opinion it would be better to focus on improving current drivers than thinking on switching into a newer programming language which will almost mean starting from scratch...

[kpedersen]

then better add [LANG_B] now, before one has to deal with [LANG_A] APIs

Adding a high(er) level language like C++ or Rust causes issues when interfacing with it from any other languages. You provided a very good example why both C++ *and* Rust should be kept out of a number of underlying codebases.

Mesa already has C++ in it so in many cases you would need to go C++ <> C <> Rust to communicate between them. This is messy, fragile, wasteful of resources and will likely also undermine many of Rust's interesting safety mechanisms anyway.

[oleid]

If there is not much c++ api in mesa, then better add rust now, before one has to deal with c++ APIs

[moltonel]

Tbh this isn't about adding Rust or C++ to Mesa code directly, but rather to Mesa drivers. I think that's a smart approach, if it doesn't pan out, you only have to revert one or two drivers.

Rereading the thread, there are also desires to use Rust in core parts like GLSL, although a driver is the pragmatic/cautious first step/experiment. Also, Mesa does use a bit of C++ already, though apparently there's still work needed to deal with the C/C++ impedance mismatch.

[bug77]

Moving from C to C++ isn't a no-brainer any more than moving from C to Rust is. C has a lot of problems, but it has served Mesa well so far, and adding any new language to a single-language project is a big ask. Adding two languages to the mix in one go is probably pushing it too far, so it makes sense to choose carefully.

C++ has more developers (especially if you put all C++ versions in the same bucket), it's well integrated with C build systems, has slightly wider platform support, and allows more niche code constructs. But compared to Rust it takes longer to become proficient with, it takes a lot more effort to secure, it has more linking/FFI issues, it has more platform-specific differences... It's a complex set of pros&cons, and rational people can reach opposite conclusions.

Tbh this isn't about adding Rust or C++ to Mesa code directly, but rather to Mesa drivers. I think that's a smart approach, if it doesn't pan out, you only have to revert one or two drivers.