▲ 435 ▼ Rust in Linux lead retires rather than deal with more “nontechnical nonsense” (arstechnica.com) submitted 2 years ago by tux0r@feddit.org to c/linux@lemmy.ml 209 comments fedilink hide all child comments Linux people doing Linux things, it seems.
[–] leisesprecher@feddit.org 18 points 2 years ago (1 child) Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it's running or being used every day. That's in no way what's been proposed. Rust is used in a very well defined niche, nobody wants to get rid of C. But it's just that sentiment that got us here, you're arguing against a non-existent threat, and thus reject the whole proposal. permalink fedilink source parent hideshow 2 child comments replies: [–] pete_the_cat@lemmy.world 1 point 2 years ago (1 child) I'm not rejecting it, I'm just saying that it's very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I'm a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I'm sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it's not as mature as C right now so that's not going to happen for a while, if at all. permalink fedilink source parent hideshow 2 child comments replies: [–] leisesprecher@feddit.org 1 point 2 years ago The long-term goal is for Rust to overtake C in the kernel (from what I understand Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon. critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit The entire kernel is "critical". The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all. permalink fedilink source parent
[–] pete_the_cat@lemmy.world 1 point 2 years ago (1 child) I'm not rejecting it, I'm just saying that it's very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I'm a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I'm sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it's not as mature as C right now so that's not going to happen for a while, if at all. permalink fedilink source parent hideshow 2 child comments replies: [–] leisesprecher@feddit.org 1 point 2 years ago The long-term goal is for Rust to overtake C in the kernel (from what I understand Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon. critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit The entire kernel is "critical". The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all. permalink fedilink source parent
[–] leisesprecher@feddit.org 1 point 2 years ago The long-term goal is for Rust to overtake C in the kernel (from what I understand Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon. critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit The entire kernel is "critical". The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all. permalink fedilink source parent