4 ms·
Community wise, yes. It seems to have gained some momentum. From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if
by varajelle 5y ago
Community wise, yes. It seems to have gained some momentum.
From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if only because you can normally just include the headers and be done with it.
(Although as the article says, there are some cleanup to do.)
- broodbucket 5y agoFrom an everything point of view, there's no point in adding complexity for no tangible benefit. Rust has tangible benefits (memory safety). Very far from a silver bullet, but demonstrably better than C. Rust isn't being experimented with in the kernel because someone decided we should really add a second language. C++ interop with C doesn't matter when there's no reason to use C++ in the kernel anyway.
- tialaramex 5y agoThe "interoperate easier" idea is a trap for both C and C++ and worth avoiding because in fact they aren't quite compatible, so you're making both languages worse to achieve this. I don't much like C++, but if you must use C++, actually use C++ and forget that it's sorta kinda "compatible" with C.
- steerablesafe 5y agoYou can create headers that are usable from C and C++, but you have to actively maintain it that way. As C headers tend to not have function definitions in them, it's fairly easy to avoid the C-only features. I doubt that Linux headers give a damn about usability from C++ though.
- varajelle 5y agoI know they are not 100% compatible, but they are 99% compatible, and that's much better than Rust. It's easy to make it compatible by not using fields called "class", or using #ifndef __cplusplus, most C library headers are actually like that. But not the Linux kernel because they refuse it. That's why I'm saying that the choice is not a technical one.