Eventually all the people who know and are good at cobol will die.
A while before that happens, the people who know it will continually demand more money for their rare skills.
Eventually, the cobol systems out there will need to interface new systems in some way it wasn’t designed to and it’ll be more expensive to shoehorn the remote system than to let the ancient beast retire.
Even if, we are talking about the Linux kernel. Our entire ecosystem builds upon C. People choosing C for new projects because it is the common denominator.
If Rust should be adopted in the kernel faster, patches should be send which comment how each line addresses issues of memory management solved and elaborations for rust specific patterns unfamiliar to a C dev.
Lurkers will pick up Rust that way as well.
Each Rust dev had to pick it up and therefore should be able to enable other - probably more experienced - Linux kernel hacker to provide reviewable patches.
It shouldn’t be the other way around, else you are just stepping on the efforts the other human provided to that project.
I’m not against Rust. I’d like to see something less dangerous with memory than C, but I don’t think it’s time yet for the kernel to leave C.
It’s pretty clean, stable, it’s working well at the moment and the C language (or variants of it) is/are still actively used everywhere. I think the kernel universally going Rust will be a long road of everything under the sun going there first before it’s ported in earnest.
The goal ATM is simply to allow people to write new drivers in rust, not convert the whole kernel to rust. It will be a very long time, before more core parts would be allowed to be written in rust let alone rewriting any existing core kernel code. Which is all fine as new drivers are a large part where bugs are added - older parts have had a long time for bugs to be found and fixed and so it is far less important to need to rewrite them.
Even if, we are talking about the Linux kernel. Our entire ecosystem builds upon C. People choosing C for new projects because it is the common denominator.
If Rust should be adopted in the kernel faster, patches should be send which comment how each line addresses issues of memory management solved and elaborations for rust specific patterns unfamiliar to a C dev.
Lurkers will pick up Rust that way as well.
Each Rust dev had to pick it up and therefore should be able to enable other - probably more experienced - Linux kernel hacker to provide reviewable patches.
It shouldn’t be the other way around, else you are just stepping on the efforts the other human provided to that project.
I’m not against Rust. I’d like to see something less dangerous with memory than C, but I don’t think it’s time yet for the kernel to leave C.
It’s pretty clean, stable, it’s working well at the moment and the C language (or variants of it) is/are still actively used everywhere. I think the kernel universally going Rust will be a long road of everything under the sun going there first before it’s ported in earnest.
The goal ATM is simply to allow people to write new drivers in rust, not convert the whole kernel to rust. It will be a very long time, before more core parts would be allowed to be written in rust let alone rewriting any existing core kernel code. Which is all fine as new drivers are a large part where bugs are added - older parts have had a long time for bugs to be found and fixed and so it is far less important to need to rewrite them.
Yes there is never old code with bugs that have been sitting there for decades.