3 ms·

Frankly, one of the best things we could do to help this hypothetical future language be adopted is to have precedent for Linux using another language. We're r

by geofft 6y ago

Frankly, one of the best things we could do to help this hypothetical future language be adopted is to have precedent for Linux using another language. We're really trying two things here - getting Linux to use some Rust, and getting Linux to use some other language, with an independent compiler. That second part is pretty significant by itself (we've had discussions about build systems, compiler ABI bugs, etc.), and even if we were just trying to add C Except Different, it would be a major project on its own. Once we've figured out how to make them interoperate and what the ground rules are (architecture compatibility, where new development goes, whether the new language can be mandatory, release timeframes, etc.), a third language will be on much better-explored territory. (I do actually think that Rust is pretty close to ideal for the Linux kernel as it currently exists, though! As I argue in https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf / https://www.youtube.com/watch?v=RyY01fRyGhM https://www.youtube.com/watch?v=RyY01fRyGhM , a lot of Rust constructs happen to match idioms and abstractions that the kernel uses with C. But yes, there's a lot of research on both good kernels and good programming languages yet to be done.)

arp242 6y ago
Right; going from n=1 to n=2 is usually a lot of work, but going on to n=3 and beyond after that is usually much easier. It's good this is finally been considered; there have been projects like this for decades but they never made much headway. I remember seeing this presentation about a memory safe driver framework over 10 years ago, and while it was functional (according to the authors) it never seemed to see much implementation (IIRC it generated C code, I can't recall the name of the project). There's also stuff like Cyclone[1], and I never understood why that never got any traction as it embodies more or less the same ideas as Rust (the homepage even recommends Rust now), and there's of course D, although the lack of adoption there can probably be explained by the licensing (D can run without a GC). [1]: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/
- ssokolow 6y ago
  As I understand it, it's because Cyclone's big advantage isn't what made Rust popular. It's that Rust combined a whole lot of attractive features in a single package, of which, memory safety without GC is only one.

by geofft 6y ago

arp242 6y ago

Right; going from n=1 to n=2 is usually a lot of work, but going on to n=3 and beyond after that is usually much easier. It's good this is finally been considered; there have been projects like this for decades but they never made much headway. I remember seeing this presentation about a memory safe driver framework over 10 years ago, and while it was functional (according to the authors) it never seemed to see much implementation (IIRC it generated C code, I can't recall the name of the project). There's also stuff like Cyclone[1], and I never understood why that never got any traction as it embodies more or less the same ideas as Rust (the homepage even recommends Rust now), and there's of course D, although the lack of adoption there can probably be explained by the licensing (D can run without a GC). [1]: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/

ssokolow 6y ago
As I understand it, it's because Cyclone's big advantage isn't what made Rust popular. It's that Rust combined a whole lot of attractive features in a single package, of which, memory safety without GC is only one.