Serious question: How can a programming language be more or less secure than another? I am just a hobbiest, not a professional, so I am genuinely curious.
My dad who is a software engineer can’t even answer my question. But then he’s old and I’ve only seen this argument coming from the young bloods.
Concrete technical answer (one of many): imagine you have a list (“array”) of 5 numbers, and you try to print the 10th number in the array. A secure language will say “error! it’s a list of 5 numbers, there is no 10th one!!”. C will instead print some random garbage (whatever happens to be in the part of memory following the 5 element list), or maybe do something even crazier (try searching “nasal demon”), without indicating that anything has gone wrong. There are many other issues like this with C. You end up with programs going completely into the weeds, turning control over to attackers, etc.
Abstract philosophical answer: Secure languages like Ada and (hopefully) Rust are designed to help you ensure the absence of unwanted behaviours, rather than just the presence of wanted ones. If you want behaviour X, the goal of old languages like C was to make sure you could write a program in which X was present. That was a big enough challenge in the old days that language designers stopped once they reached that point. If you don’t want behaviour Y (let’s say Y is a security attack), it’s up to you to just write the program without behaviour Y. 50+ years of experience have shown that to be inhumanly difficult once the program gets complicated, so you really do need help from the language. Accountants invented double-entry bookkeeping 700 years ago for similar sorts of reasons: to keep small errors in complicated systems from sending the system into a nose dive.
Ensuring the absence of behaviours is the classic problem of proving a negative, so there are limits on how thorough the checking can be, and the technical features (like the notorious Rust borrow checker) can be difficult to use. But if you’re willing to endure a certain amount of pain and runtime inefficiency (requiring the program to do a little extra work at each operation to make sure the result makes sense, like the example of the 10th element of the 5-element list), you can make programs much safer than you can in C.
Does that help?
Added: Rust is getting some flak because it is pretty new, is still a work in progress, has various unmet goals, etc. It’s not fully baked yet but it is getting there (I’m studying it right now). Ada is an older language that is way more mature than Rust, but is more of a pain to use in many ways, so Rust is currently getting more attention.
I do not think C is going to completely go away. If nothing more, it will be used as an ABI, to glue various other languages together.
On the other hand, C is going to fade out, not just for memory safety issues, but also due to “language jank”. Usually language design choices that made sense on 60’s and 70’s mainframes, but no longer needed, and later languages tried to rectify them in their “C-influenced” syntax, but had the issue of also being much higher level than C.
Also Rust is just the most hyped replacement for C, and depending on your usecase, other languages might be much better. D has a very close syntax to C without the jank, expecially when used in the betterC mode.
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.
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?
These tech images are getting pretty ridiculous. What even is this thumbnail?
It’s how everyone who’s anyone does code reviews!
Only ones who knows how to make proper tech images are the folks at O’Reily publisbing
We’ve already seen a few crotchety old timers who don’t want to add rust to the Linux kernel.
At some point, a complete rewrite of the kernel in a memory safe language would be prudent. Unfortunately, the dinosaurs will have to go extinct before that can happen.
Literally no one is stopping you
Just those crotchety old timers who currently gatekeep the code base.
That doesn’t prevent you from forking it.
The Linux kernel is a few hundred million lines of code, probably. It does need to slowly be moved into a memory safe language.
