Except in this case, it was a bunch of old C devs who aren’t just resistant but openly hostile to change, and they’d rather bully people into silence than try to progress.
In a twist of delicious fate, my instance doesn’t have downvotes. They get dropped before they even hit the database. So I’ll never know or “feel ashamed” if they don’t bother to take time to refute it. 🤣
If I go to any of the teams I interact with who program their components in C++ and proposed Rust or anything else, I’d get a similar reaction. They’re very good at C++ and they very rarely have memory and threading issues. 😂
It’s always the “rarely” that gets you. A program that doesn’t crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.
People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.
They don’t get, that without memory issue resistant language, not a lot of new blood will be as good as them dealing with that stuff since they already have that solved in the language itself.
It is about making kernel development future proof, so that new devs keep on coming and don’t create massive security holes on the way.
Note that Rust does not “solve” memory management for you, it just checks whether yours is memory safe. Initially you might rely on the borrow checker for those checks, but as you become more and more used to Rust you’ll start to anticipate it and write code that already safisfies it. So ultimately you’ll still learn how to safely deal with memory management, just in a different way.
Yeah all of the times I see Rust being described as “harder to learn” than C I just shake my head. It’s like saying that it’s easier to just fall off the cliff at the Grand Canyon instead of taking the path down. Any additional difficulty is because the language forces you to understand memory and pointers properly, instead of just letting you fuck around and find out.
I knew this ageist bullshit would pop up. I know we lost our mentors and are kinda feeling in the dark, but the moment people pop out the ageist slurs I know they’ve got nothing to say.
The C developers are the ones with the ageist mindset.
The Rust developers certainly are not the ones raising the point “C has always worked, so why should we use another language?” which ignores the objective advantages of Rust and is solely leaning on C being the older language.
“Old” doesn’t have to mean biologically old. In this case, it means people who have been doing it for a long time—long enough that they’re set in their ways.
So while I can understand the confusion, it doesn’t apply here.
Ironically the majority of the rust memory management ruleset is called ownership, and they are unwilling to release any of it, and claiming all of it, so there’s an out of memory error.
Lol the out of memory error was a joke. A reference to that two people both trying to do the same thing will fill the heap since there’s unnecessary work.
I tried to make a code joke but it failed.
As far as what are they unwilling to release? Control. Ownership of any bit of the kernel they control
kernel maintainer Ted Ts’o, emphatically interjects: “Here’s the thing: you’re not going to force all of us to learn Rust.”
Lina tried to push small fixes that would make the C code “more robust and the lifetime requirements sensible,” but was blocked by the maintainer.
DeVault writes. “Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work.”
Except in this case, it was a bunch of old C devs who aren’t just resistant but openly hostile to change, and they’d rather bully people into silence than try to progress.
God bless Douglas Adams
Several downvotes with zero comments to refute or discuss your point. Some devs don’t like you calling them out
In a twist of delicious fate, my instance doesn’t have downvotes. They get dropped before they even hit the database. So I’ll never know or “feel ashamed” if they don’t bother to take time to refute it. 🤣
If I go to any of the teams I interact with who program their components in C++ and proposed Rust or anything else, I’d get a similar reaction. They’re very good at C++ and they very rarely have memory and threading issues. 😂
It’s always the “rarely” that gets you. A program that doesn’t crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.
People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.
They don’t get, that without memory issue resistant language, not a lot of new blood will be as good as them dealing with that stuff since they already have that solved in the language itself.
It is about making kernel development future proof, so that new devs keep on coming and don’t create massive security holes on the way.
Well this is how I understand it.
And it’s a bad argument anyway. You’re only good at memory management until the first bug takes down production.
Rust isn’t a panacea and certainly has problems, but eliminating an entire class of potentially very dangerous bugs is a very good argument.
Note that Rust does not “solve” memory management for you, it just checks whether yours is memory safe. Initially you might rely on the borrow checker for those checks, but as you become more and more used to Rust you’ll start to anticipate it and write code that already safisfies it. So ultimately you’ll still learn how to safely deal with memory management, just in a different way.
Yeah all of the times I see Rust being described as “harder to learn” than C I just shake my head. It’s like saying that it’s easier to just fall off the cliff at the Grand Canyon instead of taking the path down. Any additional difficulty is because the language forces you to understand memory and pointers properly, instead of just letting you fuck around and find out.
😃I see, nice to know
I knew this ageist bullshit would pop up. I know we lost our mentors and are kinda feeling in the dark, but the moment people pop out the ageist slurs I know they’ve got nothing to say.
The C developers are the ones with the ageist mindset.
The Rust developers certainly are not the ones raising the point “C has always worked, so why should we use another language?” which ignores the objective advantages of Rust and is solely leaning on C being the older language.
“Old” doesn’t have to mean biologically old. In this case, it means people who have been doing it for a long time—long enough that they’re set in their ways.
So while I can understand the confusion, it doesn’t apply here.
Why isn’t a Rust kernel being developed in parallel ?
I mean, it is. RedoxOS is just that. But it’s not Linux and that means a lot of things.
Maybe this is the fork in the road for something new. These circumstances were kind of how GNU/Linux was born, after all.
Rust for Linux used to be developed in parallel to the mainline Linux before Linus Torvalds merged support in the main tree.
If you want to talk about bullying you ought to include all the rust zealots who show up to shit on C every chance they get.
Okay, but this was but an example of that, so it’s not really a relevant grievance, is it?
Ironically the majority of the rust memory management ruleset is called ownership, and they are unwilling to release any of it, and claiming all of it, so there’s an out of memory error.
I didn’t understood your criticism, what are they unwilling to release? What are they claiming all of? Why would ownership rules cause an OOM?
Sharing stack memory is a bad practice in C as well btw.
Lol the out of memory error was a joke. A reference to that two people both trying to do the same thing will fill the heap since there’s unnecessary work.
I tried to make a code joke but it failed.
As far as what are they unwilling to release? Control. Ownership of any bit of the kernel they control