26 ms·

While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to

While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs, and especially not with a language like Rust. Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? Is it more efficient in the long run? Will the current people working on Mesa be able to adapt to such a change (Likely irrelevant since they'd probably be the ones leading such changes in the first place if they were to occur)? Are the benefits/improvements even worth the costs in the first place? Is it sustainable (C has been around since... well forever, and it has a very rich, mature ecosystem built around it. Rust on the other hand has been around for a fraction of the time, suffers from core team (corporate) drama, and doesn't have a "fixed" standard like C does with C89/90, C99, C11, etc. as far as I know (Things might've changed in the past few months/year))? I personally can't see it as being necessary for high code quality and safety.

dcsommer 4y ago
> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dichotomy. Bugs are concentrated in new code, so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. Going backwards and rewriting low bug density code should not be a priority. Both of your alternatives only address existing code.
- Slighted 4y ago
  Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.
  - bluejekyll 4y ago
    This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.
- andsoitis 4y ago
  > so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. How well does Rust inter operate with C or C++ code? When you interoperate, do the security issues persist or do they disappear automagically?
  - Arnavion 4y ago
    There is unsafety at the FFI boundary. The C functions will deal with pointers, so the Rust side will have to use pointers too. The Rust side will normally thunk it into safe Rust (convert pointers to references by introducing lifetimes, wrapping in types with destructors, making sure to add or remove Send / Sync impls as necessary, etc) so that the rest of the Rust code that's not at the boundary can be safe. So if you have a Rust function that receives a pointer and a length representing the array, it will translate that into a Rust slice by trusting the pointer and length. Of course if the C caller gave a garbage pointer or a length that's bigger than the actual C array, then the "safe" Rust code that uses that slice will still be illegal. C++ interop has some additional complexity because of templates, methods, inheritance, etc, that's handled by the cxx Rust library. I don't know much about it.
  - bluejekyll 4y ago
    Rust allows for zero overhead FFI between itself and C. For C++, there are some crates working to make that easier so that C++ objects can be shared, but generally, the C ABI is the common interop layer. As to the security issues persisting, yes, the C security issues will persist. But, what’s nice is that the Rust code is safe and you just need to attest to the compiler that the usage of those C APIs is safe. Essentially the Rust code is safe, but it’s still your responsibility to prove that the C code is safe.
deleted 4y ago
[deleted]
conradev 4y ago
> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post: > The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed. You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/introducing-nvk.html https://www.collabora.com/news-and-blog/news-and-events/intr... If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")
estebank 4y ago
> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? One thing you're missing is that "comb[ing] through the currently existing code manually" doesn't help you in the future. Unless you have an absolute code freeze new code keeps getting written which can (depending on the language) affect the correctness of distant already reviewed code. So even if you can absolutely ensure that the code as it exists today is perfect (which is already an exceedingly thing to do), you need to keep that effort up continuously, lest a code change causes prior invariants to no longer be met.
kelnos 4y ago
> While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs A ton of data about software bugs and vulnerabilities, as well as history, seems to disagree with you here. I suppose in the most permissive use of the term "can", sure you "can" eliminate all those bugs in C/C++ code bases, but at what cost? Formal verification? A code review process that has requirements similar to those imposed on people working on spaceship and airliner avionics software? That's impractical for the vast majority of projects. It just seems more sensible to use a language that eliminates certain classes of bugs entirely. Rust does that, at least for some classes of bugs. I'll grant you that maybe Rust isn't the correct answer here, but C (and even C++) IMO need to be relegated to the past. I recently got re-involved in a C-based open source project that I used to work on ~15 years ago. In the intervening time, most of my work has been done using JVM languages, and, more recently, Rust. Going back to C has been tedious and error-prone. The language is awkward to use, and its type system is a joke. I would absolutely love to be able to work in Rust instead, or... really, anything else. > Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? Neither, and that's not what the article in question is proposing doing.
howinteresting 4y ago
The sibling comments have good points, but the actual reality is that any project that wants to stay alive and attract new developers in 10 years should probably start introducing Rust about now. Linus to his credit picked up on that.

dcsommer 4y ago

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dichotomy. Bugs are concentrated in new code, so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. Going backwards and rewriting low bug density code should not be a priority. Both of your alternatives only address existing code.

Slighted 4y ago
Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.
- bluejekyll 4y ago
  This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.
andsoitis 4y ago
> so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. How well does Rust inter operate with C or C++ code? When you interoperate, do the security issues persist or do they disappear automagically?
- Arnavion 4y ago
  There is unsafety at the FFI boundary. The C functions will deal with pointers, so the Rust side will have to use pointers too. The Rust side will normally thunk it into safe Rust (convert pointers to references by introducing lifetimes, wrapping in types with destructors, making sure to add or remove Send / Sync impls as necessary, etc) so that the rest of the Rust code that's not at the boundary can be safe. So if you have a Rust function that receives a pointer and a length representing the array, it will translate that into a Rust slice by trusting the pointer and length. Of course if the C caller gave a garbage pointer or a length that's bigger than the actual C array, then the "safe" Rust code that uses that slice will still be illegal. C++ interop has some additional complexity because of templates, methods, inheritance, etc, that's handled by the cxx Rust library. I don't know much about it.
- bluejekyll 4y ago
  Rust allows for zero overhead FFI between itself and C. For C++, there are some crates working to make that easier so that C++ objects can be shared, but generally, the C ABI is the common interop layer. As to the security issues persisting, yes, the C security issues will persist. But, what’s nice is that the Rust code is safe and you just need to attest to the compiler that the usage of those C APIs is safe. Essentially the Rust code is safe, but it’s still your responsibility to prove that the C code is safe.

deleted 4y ago

[deleted]

conradev 4y ago

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post: > The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed. You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/introducing-nvk.html https://www.collabora.com/news-and-blog/news-and-events/intr... If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")

estebank 4y ago

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? One thing you're missing is that "comb[ing] through the currently existing code manually" doesn't help you in the future. Unless you have an absolute code freeze new code keeps getting written which can (depending on the language) affect the correctness of distant already reviewed code. So even if you can absolutely ensure that the code as it exists today is perfect (which is already an exceedingly thing to do), you need to keep that effort up continuously, lest a code change causes prior invariants to no longer be met.

kelnos 4y ago

> While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs A ton of data about software bugs and vulnerabilities, as well as history, seems to disagree with you here. I suppose in the most permissive use of the term "can", sure you "can" eliminate all those bugs in C/C++ code bases, but at what cost? Formal verification? A code review process that has requirements similar to those imposed on people working on spaceship and airliner avionics software? That's impractical for the vast majority of projects. It just seems more sensible to use a language that eliminates certain classes of bugs entirely. Rust does that, at least for some classes of bugs. I'll grant you that maybe Rust isn't the correct answer here, but C (and even C++) IMO need to be relegated to the past. I recently got re-involved in a C-based open source project that I used to work on ~15 years ago. In the intervening time, most of my work has been done using JVM languages, and, more recently, Rust. Going back to C has been tedious and error-prone. The language is awkward to use, and its type system is a joke. I would absolutely love to be able to work in Rust instead, or... really, anything else. > Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? Neither, and that's not what the article in question is proposing doing.

howinteresting 4y ago

The sibling comments have good points, but the actual reality is that any project that wants to stay alive and attract new developers in 10 years should probably start introducing Rust about now. Linus to his credit picked up on that.