Mesa Developers Discuss The Possibility Of Rust Graphics Driver Code

[jacob]

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.

C++'s advantages are indeed more developers, easier integration with C build systems and with C in general, and it supports many more target platforms than Rust. I would say it's also easier to become proficient with it than Rust, which is a lot more exotic as a language especially for someone coming from C. But Rust is a better driver development language than C++; it's safe, which means it has provable properties that C++, no matter how "modern", cannot provide by design. It has excellent parallelisation and multithreading capabilities and it has a more suitable error handling model (exceptions in drivers are a big no-no). C++'s advantage for driver code is that it has a placement operator (rather crappy, but at least it has one) which Rust still doesn't and requires workarounds for that.

[oleid]

Yeah this is actually one of my major concerns.
I'm really relucant to be packed into the LLVM bandwagon

If you use mesa, you are already in the llvm bandwagon. It is used for GPU code generation.

But anyway, there are attempts to wire up the existing rust compiler fronted with gcc as backend, so hopefully you'll be able to use rust without llvm one day.

[oleid]

C++'s advantage for driver code is that it has a placement operator (rather crappy, but at least it has one) which Rust still doesn't and requires workarounds for that.

I've never used that in c++. It seems rather exotic. It seems more like something a container would use internally. Out of curiosity, do you have any (code) examples where this would make a (performance) difference?

[Delgarde]

The direct Rust<->C++ interop solutions (without going through a C ABI) are actually pretty decent. Not every C++/Rust types can be used, but it's better than C<->C++ or C<->Rust interop. It's remarkable that Rust already has this, most languages don't bother and only implement a C ABI FFI.

Not so remarkable, when you remember that Firefox is primarily a C++ codebase...

[kpedersen]

Eh? A common pain point I've heard about with C++ is it's lack of interoperability with other languages.

Yep, you will see in a previous post I suggested keeping entirely with C mostly for the interop reason (not just externally).

It isn't C++ specifically that is bad at interop, it is that *every* high level language that isn't C is bad at interop with one another.
The fact that Rust can access some C++ types is fairly unique! But there are still a few areas where bindings will need to be made if needed.

For example I don't think we will ever see a language i.e on a JVM that will be able to directly communicate with a language on a .NET VM.
Likewise for native languages, they all focus on C as the lowest common denominator. Which is why C is a very good bet.

[Delgarde]

For example I don't think we will ever see a language i.e on a JVM that will be able to directly communicate with a language on a .NET VM.
Likewise for native languages, they all focus on C as the lowest common denominator. Which is why C is a very good bet.

Actually, there were ways of running Java bytecode on a .NET VM almost from the earliest days of .NET. They're not very commonly used, but it's possible...

[Alliancemd]

It is YOU who have ZERO KNOWLEDGE about how rust works.

$ ldd `which rustc`
linux-vdso.so.1 (0x00007fffe71cd000)
librustc_driver-a65f53cf2e449c04.so => /lib64/librustc_driver-a65f53cf2e449c04.so (0x00007f4547f7e000)
libstd-ce0075fa4a63cdc8.so => /lib64/libstd-ce0075fa4a63cdc8.so (0x00007f4547e7e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4547cb4000)
[B][COLOR=#e74c3c]libLLVM-10.so => /lib64/libLLVM-10.so (0x00007f4542f33000)[/COLOR][/B]
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4542d43000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4542d3c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4542d18000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4542cfd000)
/lib64/ld-linux-x86-64.so.2 (0x00007f454bdb7000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4542bb7000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f4542bac000)
libedit.so.0 => /lib64/libedit.so.0 (0x00007f4542b6f000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4542b55000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f4542b24000)

CAN'T YOU SEE? Or are your ignorant of static linking?

LLVM is the ONLY back-end of rust compiler. This is COMMON SENSE.

I said "Rust binaries", these have nothing to do with LLVM.
Obviously the compiler depends on LLVM and not only that, for obvious reasons...

[pal666]

why he waited for rust? java was available long ago

[bug77]

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.

That's all I was saying. No matter how much I like Rust, it's not the perfect language for everything (no language is). Try it where you think it makes sense, see whether it works out for you.