A lot of the posts here talk about the need to have a very simple and easy way to use existing C code in whatever new language we want. Supposedly because for the foreseeable future we'll want to call the existing code.
I will make one counter-argument, and tell one anecdote to strengthen it.
Counter-argument: There are two kinds of C interfaces you would want to call. The first kind is things like the POSIX standard library, with functionality like open file, connect socket, and such. Those things a new language will want to wrap into interfaces that are idiomatic in the new language anyway, so normal code won't call them. And even if it did, those things are very very safe and hard to abuse (they're designed that way).
The second kind of C code you will want to call is stuff that is written by "yourself" (in big systems that usually means in-house teams). This is exactly the kind of code you want to get away from, because it is unsafe, and too often not well done. You don't want to call this code, you want to replace it with well-written and safe code.
In reality, there is a third kind of code: well-tested libraries that you acquire from outside, for example open source, or commercially (yes, commercial library code still exists, but is not often seen by amateurs). I think this category is rare, and many things in it (in particular open source code that comes from badly run development projects, see the recent xz debacle) is in the second category.
Now the anecdote. Three decades ago, I worked in a company whose main code base was 1/2 million lines of very messy C code, which had been partially upgraded with C++ features (we have a few classes), and was very badly written and unstable. The company was not a software company, many "software engineers" were part-timers from other departments (be it image processing, electrical engineering, or manufacturing technicians), and it didn't have a culture of good software processes. Since I was already a C++ expert, I was explicitly hired for the great project that was going to save the code base: A new framework, explicitly designed in C++ for safety and good coding practices, intended to be friendly for less skilled software engineers (since the reality of having to use part-time engineers didn't go away), and able to call some of the existing code after vetting it. That was a TOTAL disaster. Why? Several reasons. First, it is very difficult to write leak-free and memory-safe C++, and with the state of the language in 1997, it was virtually impossible. Second, C++ is such a hard language to master (and you need mastery to write safe code that is correct even under error conditions, while any beginner can hack up something that functions on the good path) that working a large project with not all great programmers didn't work. And most importantly: Every time you called any of the old code, things blew of left and right ... just like the old code was blowing up all the time in its normal production usage.
At this point, an important decision was made: We gave up on C++. We switched to Java, the best choice available at the time, but explicitly embedded a Python interpreter in the Java code. The single most important rule was: We will never ever call old code. Instead, we rewrite it in Java, while simultaneously documenting, sanitizing, and organizing it. If a part-time programmer who is not a skilled software engineer needs to use the system, they can write Python scripts. About 1% of the code base was determined to be performance critical, and that was re-coded from scratch in C and called via JNI. The way we did this is that a scout team of 5 people (I was one of them) implemented a tiny part of the 500K line system in Java from scratch, allowing a lot of scaffolding (no DB interfaces, no UI/UX) in one year, as a proof of concept, and to get the basic coding standards, software processes and generic libraries done. Then a rapidly increasing team of up to 150 engineers was added to the team, and within 3 years, they had re-implemented the whole thing into a functional state.
This started about 1997 or so. I last talked to former colleagues a few years ago (sadly, at the funeral of a colleague): the system is now up to 17M lines, covers a much larger product line, can do networked (cloud-like or scale-out) operation, is used by multiple corporations, and has been touched by thousands of engineers. The basic design decisions are holding up fine. Why? Because early on we decided to intentionally give up compatibility and calling old, badly written code, and making "clean design and good craftsmanship" the guiding principle.
From this viewpoint: I prefer a language that can NOT call existing C code.
talking of rust
in the 1980s my Dad had a Lancia Delta car when he lived by the sea in Brighton
and all the salt in the sea air caused the car to rust and you could poke your finger through the body work
Ah, Lancia, a close relative of Fiat and Alfa Romeo. I drove an Alfa Spider when I was a graduate student. It is the only car that begins rusting when its picture is printed in the sales flyer.
medium.com
www.zdnet.com
