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.
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.
I agree. And those decades of development come with huge advantages. Libraries. Patterns. Textbooks! Billions of lines of code you can cross reference and learn from!
It’s fun to bleed a little when you are tinkering. It’s not fun to have to reinvent the wheel because you choose a language that doesn’t have an existing ecosystem. That becomes and chicken-and-egg problem. The tinkerers fulfill this role (building out the ecosystem) and also tend to advocate for their tinkering language of choice. But there needs to be a real critical mass.
It takes decades to shift an entrenched ecosystem. Check in ten years if the following exist in languages other than C/C++: an enterprise grade database, a python(/etc.) interpreter that isn’t marked experimental, an OS kernel that is used somewhere real, an embedded manufacturer that ships the language as its first class citizen, a AAA game using it under the engine…
Like, in the last 15 years, I’m only aware of a single AAA game that used a memory safe language – Neverwinter Nights 2 used C# for part of the Electron Engine…
Rust is the most likely candidate here, although you see things like Erlang being used to make some databases (CouchDB). People see Rust being used on some real infrastructure projects that gain actual traction (polars comes to mind). Polars is an interesting use case though – it’s simply better than the other projects in its particular space and so people are switching to it not because it is written in rust at all… And honestly, that’s probably the only way this happens.
Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Yep. And it’ll be done. Yes it’ll take a while, but this is what it means for C to be like COBOL (which also still exists). But the more and more it can be marginalized the better we’ll all be security-wise.
“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.
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 …
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
I agree. And those decades of development come with huge advantages. Libraries. Patterns. Textbooks! Billions of lines of code you can cross reference and learn from!
It’s fun to bleed a little when you are tinkering. It’s not fun to have to reinvent the wheel because you choose a language that doesn’t have an existing ecosystem. That becomes and chicken-and-egg problem. The tinkerers fulfill this role (building out the ecosystem) and also tend to advocate for their tinkering language of choice. But there needs to be a real critical mass.
It takes decades to shift an entrenched ecosystem. Check in ten years if the following exist in languages other than C/C++: an enterprise grade database, a python(/etc.) interpreter that isn’t marked experimental, an OS kernel that is used somewhere real, an embedded manufacturer that ships the language as its first class citizen, a AAA game using it under the engine…
Like, in the last 15 years, I’m only aware of a single AAA game that used a memory safe language – Neverwinter Nights 2 used C# for part of the Electron Engine…
Rust is the most likely candidate here, although you see things like Erlang being used to make some databases (CouchDB). People see Rust being used on some real infrastructure projects that gain actual traction (polars comes to mind). Polars is an interesting use case though – it’s simply better than the other projects in its particular space and so people are switching to it not because it is written in rust at all… And honestly, that’s probably the only way this happens.
Yep. And it’ll be done. Yes it’ll take a while, but this is what it means for C to be like COBOL (which also still exists). But the more and more it can be marginalized the better we’ll all be security-wise.
Cattle not pets. They’re just computer languages.
“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.