Yes safe systems programming languages are still open to logic errors, but getting rid of the memory corruption bugs that C spread into the world thanks to the adoption of UNIX is already an improvement over the daily CVE entries.

Had AT&T charged UNIX at the same prices as the other OSes, instead of giving it for free to universities and I hardly believe C would matter.

It's likely C, or something like it, would still matter. C, despite, and because, of its faults, fills an important niche: It's at a higher level of abstraction than assembler, but still provides the control you need for that very low-level code that you need to write things like operating systems. Yes, it isn't as safe as the Wirthian languages that you yourself prefer, and I will say that it certainly isn't ideal for most of the purposes it's put to, but if you want a high-level assembly language, than it works well, because that's pretty much what it is.

C has stopped being a high level Assembly for quite a while now.

Most of the features people associate with C are compiler specific language extensions that any compiler writer can bother to add to his favourite language and not part of ANSI C.

Inline Assembly, CPU intrisics, SIMD, calling conventions, out of order execution, hardware transaction memory, cache line control, GPU execution, attaching functions to interrupt handlers and so on.

Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code.

The only thing has going for it, us that thanks to the economics of free, we now have UNIX flavours everywhere.

So we can only get rid of C when UNIX is not an option, and that is almost impossible.

Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it.

C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.

>C has stopped being a high level Assembly for quite a while now.

...No, not especially. It may not expose CPU-specific functionality in the spec, which is why it is somewhat portable, but it still is effectively good at the same things asm is good at. That's why C is sometimes dubbed "portable assembly"

>Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code.

Well, yeah. Asm is rigorously defined. It's perhaps the only language that has absolutely zero UB in practice (many languages CLAIM to have no UB, but if you're on multiple architectures, it's almost unavoidable, although few have as much as C): because it's totally unportable, it doesn't have to lean on UB the way C does for optimization.

>Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it.

Yeah, but C++ has... other problems.

>C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.

Now that's something I wish happened.

Rust isn't "magic pixie dust" to remove all security issues. It's just a massive improvement over what we already have -- look at how many security vulnerabilities in web browsers (which largely use Modern C++ techniques) are due to Use-after-Free bugs. Just because it doesn't prevent all bugs doesn't mean it's worthless.

If someone has the mindset that "the programming language will make it so I don't have to think about bugs" then it is guaranteed that you will have more bugs.

If you want good code, you need to think, in every language.

Bingo.

And I would go further and say: the people who prefer to leave details to others are exactly the people who will write filesystem race conditions like this bug and not understand what they have done.

You need to worry about less things in Rust.