2 ms·

IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are s

by DSMan195276 2y ago

IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are still in wide use in the kernel. Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.

steveklabnik 2y ago
You're not wrong, but at this point, there's close communication between the Linux folks are the Rust team, and the Rust team has committed to stabilizing things that the Linux team needs. There is basically no chance that suddenly one of the core things they need is going to disappear. They've already gone through the list and checked that it's all stuff that is eventually going to land.
mustache_kimono 2y ago
> Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release. I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making? Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard. Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list. So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.

steveklabnik 2y ago

You're not wrong, but at this point, there's close communication between the Linux folks are the Rust team, and the Rust team has committed to stabilizing things that the Linux team needs. There is basically no chance that suddenly one of the core things they need is going to disappear. They've already gone through the list and checked that it's all stuff that is eventually going to land.

mustache_kimono 2y ago

> Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release. I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making? Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard. Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list. So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.