C is going to be around and useful long after COBOL is collecting dust. Too many core things are built with C. The Linux kernel, the CPython interpreter, etc. Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Even Fortran has a huge installed base (compared to COBOL) and is still actively used for development. Sometimes the right tool for a job is an old tool, because it is so well refined for a specific task.
“It’s too much work, so let’s just not do anything and stubbornly stick with a problematic unsafe language that fewer and fewer people are willing to learn”
It’s like the Brits trying to convince everyone else to switch to their electrical socket. Sure, the design is better for higher voltage and current, has all these extra safety features, etc. But you cannot dramatically shift an entrenched ecosystem for free.
But still, nothing new should be written in it and everything old should be rewritten or deprecated over time. Entrenched and around, yes, useful…no
There’s very little benefit to starting something new in C and a whole lot of downsides. At least FORTRAN and COBOL have niche use cases. C doesn’t really have a good niche case that something else newer and more secure can’t fill AFAIK
The problem is switching for enterprises because of how much momentum there is. Especially in embedded.
I worked on a 30 year old C code base that’s still being developed now for future products. Some components are literally 20+ years old mostly untouched. Sure they could switch to Rust or something but they’re fucked since nearly none of the staff have relevant experience in anything but the in house C build system and changing over multiple thousands of C files to another language will literally take years even if you got people trained up.
Plus, in embedded pretty much no big HW supplier provides BSPs or drivers in anything but C. If NXP etc. aren’t giving you anything but C, management doesn’t want to start combining languages.
I advocated for Rust when we started a ground-up new project, but got shot down every which way. Only those younger than like 35 were into the idea. Old managers are scared of anything new and their whole life has been C. I don’t know how you convince those kinds of people and maybe we’ll get some movement in another 10 years but enterprises are a slow cautious mess.
People tend to be obsessed with bleeding edge technology. But those who truly understand know that “bleeding edge” is an anti-pattern and there’s a reason it’s called that: it can bleed you as well.
That’s the thing, it is broken and there is a fix desperately needed. C lacks memory safety, which is responsible for many, many security vulnerabilities. And they’re entirely avoidable.
Remove the need to, yes. Remove the ability to? No, and rust doesn’t prevent you from doing that, it just makes you mark it unsafe so that way if you fuck up and cause a memory error, the root cause can be narrowed down to a tiny fragment of the code base.
No.
C is going to be around and useful long after COBOL is collecting dust. Too many core things are built with C. The Linux kernel, the CPython interpreter, etc. Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Even Fortran has a huge installed base (compared to COBOL) and is still actively used for development. Sometimes the right tool for a job is an old tool, because it is so well refined for a specific task.
Forth anyone?
The rewrite-it-in-rust gang arrives in 3, 2 …
“It’s too much work, so let’s just not do anything and stubbornly stick with a problematic unsafe language that fewer and fewer people are willing to learn”
Certainly, if I had said that.
It’s like the Brits trying to convince everyone else to switch to their electrical socket. Sure, the design is better for higher voltage and current, has all these extra safety features, etc. But you cannot dramatically shift an entrenched ecosystem for free.
Yea, mb, on reread yea.
But still, nothing new should be written in it and everything old should be rewritten or deprecated over time. Entrenched and around, yes, useful…no
There’s very little benefit to starting something new in C and a whole lot of downsides. At least FORTRAN and COBOL have niche use cases. C doesn’t really have a good niche case that something else newer and more secure can’t fill AFAIK
The problem is switching for enterprises because of how much momentum there is. Especially in embedded.
I worked on a 30 year old C code base that’s still being developed now for future products. Some components are literally 20+ years old mostly untouched. Sure they could switch to Rust or something but they’re fucked since nearly none of the staff have relevant experience in anything but the in house C build system and changing over multiple thousands of C files to another language will literally take years even if you got people trained up.
Plus, in embedded pretty much no big HW supplier provides BSPs or drivers in anything but C. If NXP etc. aren’t giving you anything but C, management doesn’t want to start combining languages.
I advocated for Rust when we started a ground-up new project, but got shot down every which way. Only those younger than like 35 were into the idea. Old managers are scared of anything new and their whole life has been C. I don’t know how you convince those kinds of people and maybe we’ll get some movement in another 10 years but enterprises are a slow cautious mess.
People tend to be obsessed with bleeding edge technology. But those who truly understand know that “bleeding edge” is an anti-pattern and there’s a reason it’s called that: it can bleed you as well.
If it ain’t broken, don’t fix it.
That’s the thing, it is broken and there is a fix desperately needed. C lacks memory safety, which is responsible for many, many security vulnerabilities. And they’re entirely avoidable.
So the solution is to take away any agency the developer may have over how their application allocates memory?
Remove the need to, yes. Remove the ability to? No, and rust doesn’t prevent you from doing that, it just makes you mark it
unsafeso that way if you fuck up and cause a memory error, the root cause can be narrowed down to a tiny fragment of the code base.Have you heard of the
unsafeblock in rust?Anti Commercial-AI license