And being stuck forever with a language that was invented over 50 years ago doesn't seem like a good idea either. If we want to take full advantage of the last half-century of PL research, we should just abandon Linux at some point and go with a completely new codebase instead? (Actually, that sounds kinda good to me, but I get why that may not be the best decision.)

I feel like the crux of your argument here is that because C is 50 years old and research into programming languages has occurred in that same 50 year period that C is now automatically bad.

What if there's nothing wrong with its intended purpose? The wheel has been around for some time, there has been research into other axle-mounted components surely we replace the wheel then?

I don't understand the "it's old therefore bad" argument.

C is, in fact, bad. The moment it was released. It's so bad that one of the designers of Algol once quipped "Algol60 was an improvement over many of its predecessors, and many of its successors"[1], I had no doubt C was at the forefront of his mind when he said that. It was already a decade old when it was first released. Its wide use is a textbook example of path dependence and fashion worship that plagues software engineering, because it was distributed freely along with Unix, and Unix was the hot new free thing.

GP was just emphasizing how old and crumbling that fossil is with the 50 years old remark.

>What if there's nothing wrong with its intended purpose

And what, exactly, is its intended purpose ? It was to rewrite a 10K LOC kernel maintained by a core team of 3 developers from PDP-7 assembly, in an age before the personal computer and the internet. It was literally created as an ad hoc, bug ridden and unspecified implementation, starting with the thinnest dressing over assembly and adding the absolute bare minimum required for a human to write ~10K LOC without gouging their own eyes off.

There is plenty wrong with it.

>I don't understand the "it's old therefore bad" argument.

It's easy. Fields where there are progress invalidates and supersede their own widsom. You wouldn't go to a doctor trained 50 years ago if you could help it. You wouldn't drive a car made 50 years ago. The only fields where that's not the case is stagnating one, like building houses or making furnitures. Things where 'progress' consists of irrelevant-to-quality changes.

Programming language design is in the first category, and not the second. Especially in the period from 1975 to 2000, it learned and discovered so much that languages made before that period might as well be cave man scribbling on cave walls.

[1] https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol...

Given the state of undefined behavior in the standard, I'm inclined to agree with you.

With that being said, can you recommend a modern language designed around a model of computation flexible enough to target e.g. non-flat memory models?

I'm additionally interested in targeting MCUs with no ISA-supported stack and ~2KiB of RAM.

You're assuming that newer stuff is always better. Experiences with operating systems don't quite confirm this, though. There has been plenty of operating systems in newer languages, and nobody remembers them.

Isn't parent's very first line, in fact, about how a newer thing was much much worse?

And the reason of that is language choice?

> What if there's nothing wrong with its intended purpose?

But there is. See the long, long, so very long list of vulnerabilities caused by incorrect memory management.

> I don't understand the "it's old therefore bad" argument.

It's a bad argument, and it's not the argument the person you're replying to is making.

C is bad for reasons that are mostly disconnected to its age. Better languages were written in the 1960s and 1970s, and worse languages are written today. What the GP is saying is that C has not meaningfully improved over the last half century.

> I feel like the crux of your argument here is that because C is 50 years old and research into programming languages has occurred in that same 50 year period that C is now automatically bad. > > What if there's nothing wrong with its intended purpose?

So is it your position that C is the pinnacle of systems programming languages? That no significant improvement in PLs has been made... that could ever be made?

I'm a Rust fanboi, but I totally get why some people don't like it. And why many people believe that something better (in one or more different directions) is possible. Or that something else would an even better fit for Linux kernel development.

If the formally proven stuff gets more traction, I'd likely jump ship to something like that. Though a lot, lot of work needs to be done there, especially when talking about interacting with hardware... such a headache. But if our base computing infrastructure could be proven to be correct (hardware and software), that could dramatically improve the entire software ecosystem. There would still be problems, but if we can at least move them up a level or two in the software stack, we have an easier time finding and fixing them. This is the difference between the Spectre attack and leaving the permissions for a password file wide open.

I don't know what a better future is going to look like exactly, but I know that we're not going to get there with just good old C code.

> Adding bindings for a second language after 25 years is not what I'd call "diversity".

Actually, a third language. The Linux kernel already has two: C and assembly.

Only if you consider all assemblies to be the same! Otherwise, many, many more.