"Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C."
This one is the main point. Highest possible speed while consuming as little resource as possible. Put in checks, and most of those checks will run redundantly compromising performance.
While true, its lack of restrictions is also a hinderance in terms of performance. As pointers can overlap by default (unless you throw a __restrict on them), a whole class of optimizations cannot be performed. That's why Fortran and Rust can in theory beat C from a performance perspective even though they do more checking as a rule. That's just one example, but it's a pretty big one.
"We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine."
Yep. A few years ago I implemented a skip list based rope library in C[1], and after learning rust I eventually ported it over[2].
The rust implementation was much less code than the C version. It generated a bigger assembly but it ran 20% faster or so. (I don't know why it ran faster than the C version - this was before the noalias analysis was turned on in the compiler).
Its now about 3x faster than C, thanks to some use of clever layered data structures. I could implement those optimizations in C, but I find rust easier to work with.
C has advantages, but performance is a bad reason to choose C over rust. In my experience, the runtime bounds checks it adds are remarkably cheap from a performance perspective. And its more than offset by the extra optimizations the rust compiler can do thanks to the extra knowledge the compiler has about your program. If my experience is anything to go by, naively porting C programs to rust would result in faster code a lot of the time.
And I find it easier to optimize rust code compared to C code, thanks to generics and the (excellent) crates ecosystem. If I was optimizing for runtime speed, I'd pick rust over C every time.
The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.
Valgrind's memcheck is great for exercising known paths in a program, and determining whether they're likely to contain memory errors. It doesn't help you discover those paths, which is what attackers are doing when they research and then exploit your program.
We've known for decades that compiler mitigations, fuzz testing, and dynamic instrumentation are excellent and necessary components of writing more secure C. But they don't secure C programs, because C itself is fundamentally unsafe.
> No, they're not static tools but being dynamic has a host of advantages too.
I think the main point is that a good alternative C doesn't compete directly with C's strongest points.
Here, you can of course make a more safe language without runtime penalty just by supporting richer build-time/static checks, but the modest and meaningful gains you make within that constraint will never be enough to displace C.
You need to be providing something meaningfully more in areas where C hasn't already squeezed out most gains. The OP tastefully avoided making this article directly about C3, but if you go and look at the summary of features, you can see how this philosophy connects with what they're working to build.
C is used because it has to be used, i.e. low level environments etc. not because 'performance' most of the time.
If you could pay in performance a little bit, but have a clean, portable, beautiful debugger experience, nice libraries like 'Java' with a 'stable ABI' ... nobody would use C. We'd all use 'that new thing'. And we would just buy slightly faster hardware for the IoT whatever.
We use C++ smart pointers all over the place, and they come with a 'cost'. We mostly 'happily pay the price' because it's worth it most scenarios.
Engineers obsession with performance is a bit of a curse. Rarely do we really need that much. Kernel code, sure, IoT and remotely controlled toy cars, mostly not.
This one is the main point. Highest possible speed while consuming as little resource as possible. Put in checks, and most of those checks will run redundantly compromising performance.