C isn't a programming language anymore (2022)

- unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.

- aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword.

There are more but I understand the logic/usability/history behind them. The above points should have been addressed in the 80’s.

As if you could separate Unix from C. Without C there wouldn't have been any Unix to become popular, there wouldn't have been any coattails to ride.

C gave Unix some advantages that other operating systems of the 1970s and 80s didn't have:

Unix was ported to many different computers spanning a large range of cost and size, from microcomputers to mainframes.

In Unix both the operating system and the applications were written in the same language.

The original Unix and C developers wrote persuasive books that taught the C language and demonstrated how to do systems programming and application programming in C on Unix.

Unix wasn't the first operating system to be written in a high-level language. The Burroughs OS was written in Algol, Multics was written in PL/I, and much of VMS was written in BLISS. None of those languages became popular.

IN the 1970s and 80s, Unix wasn't universal in universities. Other operating systems were also widely used: Tenex, TOPS-10, and TOPS-20 on DEC-10s and 20s, VMS on VAXes. But their systems languages and programming cultures did not catch on in the same way as C and Unix.

The original Macintosh OS of the 1980s was no competitor to Unix. It was a single user system without integrated network support. Apple replaced the original Macintosh OS with a system based on a Unix.

That isn't really a problem any more (since c99). You can define it as uint64_t.

But we have a ton of existing APIs that are defined using the wobbly types, so we're kind of stuck with it. And even new APIs use the wobbly types because the author didn't use that for whatever reason.

But that is far from the only issue.

128 bit ints is definitely a problem though, you don't even get agreement between different compilers on the same os on the same hardware.

Take the "wobbly types" for example. It would have been more "minimal" to have types tied directly to their sizes instead of having short, int, long, etc.

There isn't any reason that compilers on the same platform have to disagree on the layout of the same basic type, but they do.

The complaints about parsing header files could potentially be solved by an IDL that could compile to c header files and ffi definitions for other languages. It could even be a subset of c that is easier to parse. But nothing like that has ever caught on.

https://dl.acm.org/doi/abs/10.1145/3133850.3133867