I love C but I think most of the C standard library is useless and outdated rubbish (pretty much everything above the mem...() and math functions). The entire IO and memory-management areas should have been either thrown out of the standard library, or updated 20 years ago to keep up with low-level operating system features.

But one of the best features of C is that you can mostly ignore the standard library and still enjoy "C the language", e.g. nobody ever choose C for its standard library ;)

(also re UB etc...: use the mighty trio UBSAN, ASAN and TSAN!)

There's a lot of subtly broken stuff in C stdlib. For example, time.h calls that may touch the TZ env var aren't thread-safe, because getenv is unsafe (it gives a pointer to its internal globally mutable data structure without locks).

Because C is so bare-bones, it usually leans on POSIX as its extended standard library, and that is also full of old cruft.

Locale handling and most of the str* function in libc indeed are quite bad. The only sane function for "C strings" is snprintf.

That [1] is a top-quality rant, but I fear for the author's blood-pressure

Exhibit B: yes, the command that repeatedly prints `y` to stdout. Exhibit C: all handling of time, with time_t, struct timespec, timeval etc. We should just have a 64 bit uint representing nanoseconds from epoch, which would give us 585 years and get rid of much nonsense.

[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c

the over-zealous compiler writers is getting a big problem. I remember a while ago there was a proposal of a friendly c standard.

> The underlying cause is zero-terminated strings (instead of using start/end pairs or start/length pairs).

What type (and how big) should length be?

> Also: String handling, which is responsible for so, so, so many security vulnerabilities.

That's not really a counter-example. Sure the string handling was an unfortunately choice but it is the standard. The standard library must implement it as defined. Being standard-compliant is not lack of polish.

> You can't even tokenize a string without either copying or modifying

rust-lang saves the day, yet again https://www.brandonsmith.ninja/blog/favorite-rust-function

One word: strtok

It takes more code to use it correctly than to hand-code what you think it is supposed to be doing for you. strtok is Cursed.

strlcpy is similar. If you don't write that much more code, you are not using it correctly, and it is not giving you the value that is the reason you thought was why you were using it.

A single counter-example doesn't make it all wrong.

Perhaps a committee was involved.

> C won the competition because it just gives programmers the bare minimum functionality to put an operating system and a compiler in place!

Not really. C won because it was the standard compiler for Unix, and was a free compiler for a free operating system in a time when both were highly unusual.

But in the past few decades, C has lost a lot of its market share to other programming languages. In the realm of desktop (and mobile) applications, C is basically unused for new projects--its standard library is truly anemic here, and major support libraries (e.g., GUI toolkits) are often in C++ and not C. Where C is still the dominant language is the land of embedded applications, and it's not had a lot of competition here since most languages don't bother trying to define a freestanding implementation.

Rust is really the first language to try to contend this space. And there are signs that it may supplant C: Intel is apparently looking to move its firmware to Rust; Linux is allowing Rust for device drivers and kernel modules. Hell, even some OS programming courses (e.g., Stanford, Georgia Tech) have moved their curriculum to use Rust instead of C.

You probably don't realise it, but you're cheating.

Operating systems are currently written in C, and therefore have a C interface. Which language is best at interfacing with C? (No trick here, just a rhetorical question.) C of course. Other languages would need some sort of FFI, which is generally unwieldy enough that the designers hid it behind a comprehensive standard library.

C doesn't need an huge library to be available, you say? Oh but it does. It's called the kernel. Comes with a freaking huge runtime too.

> Imagine if you need to write a new OS, a compiler, a linker, or a shell interpreter... you get the idea.

I think I do, but I'm afraid you don't. Writing an OS (and the rest) in Pascal (I'm thinking of Oberon specifically) is no harder than to write it in C. If you write your whole OS in Blub, interfacing with Blub will be easiest in Blub, you won't need an extensive Blub standard library because you already have the kernel, all the tools (debuggers, editors…) will be Blub friendly…

Lisp machines used to be a thing, you know.

> My conclusion is that language designers still didn't get what made C so successful […]

Language designers can't even address what makes C so successful: network effects.

> First it was C++ (we know how well it did...)

it did well enough that C stdlibs (at least MSVC's, LLVM's) and compilers (... pretty much all the big ones) are implemented in C++ and just export C symbols nowadays, likewise for newer OSes like Fuschia.

SerenityOS (https://github.com/SerenityOS/serenity) was written from scratch in two years in C++ and goes as far as having a custom web browser & JS engine. Where is the equivalent in C ? Where are the C web browsers, C office suites, C Godot/Unity/Unreal-like game engines ? Why is Arduino being programmed in C++ and not C ?

Language designers are pretty clever people and understand a great deal about the successes and failures of languages. I think if you look at a lot of what Rust is doing today (and C++ yesterday, for better or worse) you'll see a lot of inspiration and influence from the successes and failures of C. Particularly when it comes to safety and generic programming.

Objective-C, Java, Swift, and C# have become massively successful as application programming languages because C is/was terrible at it. They learned a lot about how painful it was to do basic higher level programming tasks when you are restricted to C's semantics and memory model.

C is great but I don't think it's worth romanticizing since history has shown that C isn't that great for writing anything but systems code. Which is a restricted domain to begin with, and isn't even that attractive for it anymore.

The one thing C has over anything else is interop. The language of FFI is C. There's no inherent reason for that other than history, and it's not super broken so we're not going to fix it.

C won over because of the mystique of the syntax in which you can load multiple side effects into expressions. The intuition was that this leads to faster code, and in fact, with naive compilers, it did lead to faster code. C's terseness won over programmers who hated typing things like BEGIN and END for delimiting blocks. Unlike Pascal or Modula, C came with something very useful: a macro preprocessor. This is such an advantage, that it's better to have a crappy one than none at all. Those programmers who did not hate BEGIN and END could have them, thanks to that preprocessor. The preprocessor also ticked off a checkbox for those programmers who were used to doing systems programming using a macro assembler.

C started to be popular in the microcomputer world at a time when systems programming was being done in assembly languages. For instance, most arcade games for 8 bit microcomputers, were written in assembler. Some applications for the IBM PC were written in assembler, such as WordPerfect.

The freedom with pointers thanks to arithmetic would instantly make sense and appeal to assembly people, who would find a systems language without pointer flexibility to be too strait-jacketed.

I see C as a minimally-viable HLL. Just the essential high level stuff – expression-oriented syntax (a huge thing over assembly), structured programming support (conditionals, loops), automatic storage management (no worries about what goes in registers and what goes at certain offsets in the stack frame), abstraction over calling conventions, and a rudimentary type system around scalars with a certain size and pointers pointing at them.

I'm in a similar position (only 10 years professionally though). I agree with everything you said, except I think Rust genuinely has a shot here. It doesn't have a runtime, and you can choose to use just the core libraries or even no standard libraries. It exports to the C ABI, so it's compatible with existing software and libraries. It isn't a garbage pile like C++. And it solves a real problem C has, code safety. It's silly to say any language will completely replace any other language, but I think Rust fits into the slot pretty well for the vast majority of cases where C is currently the best choice.

    #[bla(foo)]

    fn print_refs<'a, 'b>(x: &'a i32, y: &'b i32) {
        println!("x is {} and y is {}", x, y);
    }

    impl<'a> Default for Borrowed<'a> {
        fn default() -> Self {
            Self {
                x: &10,
            }
        }
    }

I would argue that Java and C# completely succeeded. Who is out there writing Desktop applications or web services in pure C anymore?

C++ too to a lesser extent. I work on spacecraft flight software, and there's a significant push to move from pure C to modern C++.

No single language is going to (or wants to IMO) replace C in every single use case, but replacing C in specific use cases has been a huge boon for productivity.

I like C fine, and I also taught it when I was in grad school.

New languages mostly don't replace existing ones. Rather, they supplant them for some uses, and open up new kinds of software which are easier to implement or to conceive with the new language. Now, you referred to C++ specifically, and since I'm somewhat familiar with it I'll address some of the points you made with respect to just that one:

C++ was not intended to "replace C", but rather to combine features of BCPL (later C) and Simula. See: https://www.youtube.com/watch?v=69edOm889V4

Bjarne Strousup said: "If you want to create a new language, a new system - it's quite useful not to try to invent every wheel." For a long while now, C++ teachers/trainers encourage their audience _not_ to think of C++ as an "augmented C" or "C with feature X Y and Z", and to avoid most "C-style" code in favor of idioms appropriate to what the language offers today.

Also, C didn't "win the competition" because there isn't a "bestest language for everything" competition. It has been, and is, a popular language with many uses. Writing operating system kernels is one kind of programming task, where C is the most popular. Even at this level (and lower still), other languages are potentially interesting and often used. See, for example:

* IncludeOS - Running C++ without an operating system: https://www.youtube.com/watch?v=cQPrtTsM7Zg * Generating optimal assembly in an embedded setting at (C++) compile time: https://www.youtube.com/watch?v=CNw6Cz8Cb68

Finally, C++ doesn't require a huge library nor a complex runtime system because it has a "freestanding mode" in which the requirements are very limited (although more is required than for C). See: https://en.cppreference.com/w/cpp/freestanding

If you use D as Better C, it does not require anything other than the existence of the C standard library. Here's "hello world" in DasBetterC:

    import core.stdc.stdio;
    int main() {
        printf("hello world!\n");
        return 0;
    }

and yes, it is calling C's printf. To build it:

    dmd -betterC hello.d

Thank god for C winning that battle.

Imagine a world where most the languages follow Lisp's syntactic conventions, or Pascal's. What a nightmare.

   var x: *int;

   int* x;

The funny thing about rolling over an integer not being easy to catch is hard to ignore. The PDP-11 'add' instruction sets the 'C' bit if there is a carry from the MSB; the Z bit is set if the result == 0; the N bit is set if the result < 0; and the V bit is set if there is arithmetic overflow (both operands were of the same sign, but the result is of opposite sign). By simply making these bit available as, say, special names that could be tested (e.g. C N Z V) after an operation, you could determine what happened (if appropriate) and take action. HP's SPL had such a feature (used on the HP3000 series). C is not a well-designed language, but an improved 'lifeform' along the way. Today, I would like to see a c-like language developed specifically for RISC-V; especially one that had many many fewer edge cases.

  if (((a > 0) && (b > 0) && (a + b) < 0) ||
      ((a < 0) && (b < 0) && (a + b) > 0)) { / * Overflow */ }

Don't forget that these two are the same:

   0[x]
   x[0]

> * There's a standard ABI

there's one ? the "C" ABI is just the ABI of whatever platform it's running on, which may or may not have funky behaviour that vendor-provided compilers kindly hide for you - functions being prepended with '_' on macOS, the two-dozen calling conventions on windows with i386, sysv and itanium ABIs...

Do you think you can tell what's the ABI of

    struct foo some_function(struct bar);

?

will bar be passed in a register, on the stack ? who knows, that depends on your platform, your compiler, etc etc. Things going cleanly on the stack is just a convenient lie that your first year comp. sci teachers tell you because it's too early to talk about how the real world works yet.

An advantage of Rust and Golang (and OCaml actually[1]) is they let you write to the C ABI. We've written both components that call into existing C ABI (nbdkit-{rust|golang}-plugin), and also Rust/Golang/OCaml shared libraries that present C ABI functions / structures to the world.

[1] But you need to write a bit of C glue code for OCaml so it's not quite so seamless.

The ABI may come from C, but it's not limited to C. Many other languages have FFI and use the C ABI as the lowest common denominator.

But the C ABI is awful to work with. The C language itself offers no help to guarantee ABI compatibility. What ABI it compiles for depends on headers, which may depend on a jungle of ifdefs and typedefs.

What standard ABI? If I look at the gcc man page, there is a large number of abi related knobs.

One reason would be template metaprogramming. In game development and simulations we use numerical computing most of the time, a domain where templates come in handy. The rest is just C. Modern C++ for highly efficient systems is not C with classes anymore, it is more like C with templates. And also functional constructs for specific components (physics) where it makes sense to use it. I have high hopes that a language like Zig will prove less complex and as powerful as C++ for game dev. It won't be a replacement for C++, just an alternative, hard to believe that anything will dethrone the king.

The "we have to" is because all the game development middleware is written in C++ (and sometimes C), the same way you "have to" use Javascript for writing web applications (even though WASM is beginning to change that, but it took 25 years to get there).

Actually, only half of the universe is using C++ to write games, the other half is using Unity and writes their game code in C#.

If language interopability would be dramatically better, this "lock-in" into a specific programming language wouldn't be half as bad as it currently is, and it would be much easier and less risky to use "fringe languages" for game development.

Yeah, but "basically C" isn't C. The little bit extra can make a big difference.

>The features used we basically C.

Check out the Doom 3 source code ;-)