3 ms·

Mixing Rust and C in Linux likened to cancer by kernel maintainer

13 points by jjgreen 2y ago

somanyphotons 2y ago
Lots of discussion on LWN: https://lwn.net/Articles/1006805/ https://lwn.net/Articles/1006805/
mycall 2y ago
Imagine some AI converting all of the linux kernel source code into rust someday. Would kernel devs move over to rust and ditch the C tree?
codingbot3000 2y ago
While I do agree that more Rust probably makes any C or C++ code base more secure, I can feel Hellwig's (the maintainer) pain. Even compared to C, Rust is often a PITA, and in fact tends to make things less readable in my experience. I think the readability part of Rust in the kernel is often underestimated. Nevertheless, it is good to see that Linus is committed to try out Rust in the long run, which is very good for Linux I think.
badfishblues 2y ago
I think any one who has worked with a code base that has to interop between languages understands some of the pain here. There have been projects I've been a part of that interop between C, C++, C#, and Python, with mandatory support for Matlab. This is a nightmare for maintainability. It typically ruins the advantages of every language with lifetime management. No more RAII in C++, everything is IDisposable in C#, Python and Matlab support require very specific version management. It also leads to situations where it is exceedingly difficult to find references to given functions, as methods get wrapped into different languages. Error handling mechanisms frequently cannot cross language boundaries, leading to situations where you have to do conversions. Often it also leads to non-idiomatic language code, as each language has a different idiom. It leads to silo-ing, because certain developers are better with some of the languages than others. It can lead to contention because someone wants to implement something in the language they prefer. Bindings are also annoying to maintain.
- ammo1662 2y ago
  Agreed, the biggest problem of such project is where is the boundary. Once you implemented some fundamental features in language A, others will be forced to use that language for succeeding jobs. Even if you have already implemented some functions in language B, due to the limitation of integration, error handling or some other more important reasons, you still need to choose language A. Maybe after a lot of discussion, a solution can be finally reached. However, the effort consumed, or like now, causing personnel turnover, will significantly increase the cost of project. IMO if there is no extremely important reason, do not mix multiple languages within one project. If must, define some boundaries at the initial stage. Any attempt to change these boundaries should require agreement from everyone involved.

13 points by jjgreen 2y ago

Lots of discussion on LWN: https://lwn.net/Articles/1006805/ https://lwn.net/Articles/1006805/

Imagine some AI converting all of the linux kernel source code into rust someday. Would kernel devs move over to rust and ditch the C tree?

codingbot3000 2y ago

While I do agree that more Rust probably makes any C or C++ code base more secure, I can feel Hellwig's (the maintainer) pain. Even compared to C, Rust is often a PITA, and in fact tends to make things less readable in my experience. I think the readability part of Rust in the kernel is often underestimated. Nevertheless, it is good to see that Linus is committed to try out Rust in the long run, which is very good for Linux I think.

badfishblues 2y ago

I think any one who has worked with a code base that has to interop between languages understands some of the pain here. There have been projects I've been a part of that interop between C, C++, C#, and Python, with mandatory support for Matlab. This is a nightmare for maintainability. It typically ruins the advantages of every language with lifetime management. No more RAII in C++, everything is IDisposable in C#, Python and Matlab support require very specific version management. It also leads to situations where it is exceedingly difficult to find references to given functions, as methods get wrapped into different languages. Error handling mechanisms frequently cannot cross language boundaries, leading to situations where you have to do conversions. Often it also leads to non-idiomatic language code, as each language has a different idiom. It leads to silo-ing, because certain developers are better with some of the languages than others. It can lead to contention because someone wants to implement something in the language they prefer. Bindings are also annoying to maintain.

ammo1662 2y ago
Agreed, the biggest problem of such project is where is the boundary. Once you implemented some fundamental features in language A, others will be forced to use that language for succeeding jobs. Even if you have already implemented some functions in language B, due to the limitation of integration, error handling or some other more important reasons, you still need to choose language A. Maybe after a lot of discussion, a solution can be finally reached. However, the effort consumed, or like now, causing personnel turnover, will significantly increase the cost of project. IMO if there is no extremely important reason, do not mix multiple languages within one project. If must, define some boundaries at the initial stage. Any attempt to change these boundaries should require agreement from everyone involved.