Why we still use C despite so many C alternatives



C is a very old language, and it has problems that can’t realistically be fixed by updating the language, at least in any realistic time frame. In the past few years, there’s been a larger shift towards people looking at C alternatives to get into low-level programming. Today, I’ll compare a few, and explain why none of them will every fully replace C.

My website:
My github:

MORE ABOUT THE ZIG STUFF:
While Zig absolutely does have good C interop, it doesn’t guarantee ABI compatibility for everything, and it doesn’t provide “solutions” for a lot of its types in C contexts, so there’s no way to use something like an error set/union in C code, and because `extern` has to be applied to structs individually at their declaration site, things like `std.ArrayList` aren’t easily usable across language boundaries.

C3 is C ABI-compatible by default, which means everything in the language is designed to still work with C. This also extends to C3’s own features, like its error handling. C3 has carefully designed its features to be maximally compatible. That’s why C3’s “optional types” don’t have a mechanism of specifying where they came from: the goal is to trivially usable from C, so they’re actually just `void *` that point into a per-module table.

That’s why I said that Zig’s C compatibility isn’t as good as C3’s, despite them both theoretically just allowing you do `extern`/`export` the function and call it a day.

source

24 Comments

  1. CORRECTIONS:

    1:101:18: Infinite loops with no side effects, whose conditions are constants are well defined in C, and recently C++, however loops whose conditions are not constant can be assumed to terminate. How that affects this loop, I'm not 100% sure. The UB of the signed overflow means that theoretically it could be replaced by the constant, but I don't exactly know how that applies in practice. That's UB for you, I suppose.

    5:405:45: There is no C26, and this code wouldn't work. There was a drafted proposal (WG14 N2366 with more readable examples in WG14 N3032) to allow a similar behavior, when the type name is specified, allowing `struct foo {int a; int b;}` to be declared multiple times and always refer to the same type, so `#define Slice(T) struct Slice_##T { T *data; size_t len; }` would be valid for use in declarations like `Slice(int) my_ints` or `Slice(char) read_file(const char* filepath)`, but that's not exactly the same. My fault for trusting a youtube comment 😛 (sorry about the formatting, youtube is weird)

  2. I like C3. It is a very neat and well-thought out language. What I don't like is the hairbrained naming conventions and the insistence on using typenames like "unsigned long long" instead of uint32, and their resistance to changing that. Other than that, it is a very, very nice language.

  3. this is a very good video.. you touched all the points, and compared with the actually most-closer alternatives to "modern C" … I'm actually using ODIN and love it, but sometimes i miss the primitive-low-level unsecure C tricks-hacks..

  4. Creo que gracias a los LLMs para código ya no necesitamos aprender lenguajes de programación desde 0, la lógica es la misma, y con el correcto auto-completado y auto-corrector, solo es cuestión de darle un vistazo a la documentación, escribir lo que tienes em mente, y dejar a un LLM que corrija los errores. Eso es lo que vengo haciendo, yo sé lo que estoy haciendo y como hacerlo, pero traducirlo a sintaxis es la parte compleja. Ahora con LLMs puedo dejar que cada lenguaje brille en lo suyo, quiero hacer un CLI, uso Go, quiero hacer programación embebida, uso Zig, quiero hacer un juego, uso Odin. A César lo que es de César.

  5. I don't know how much of your argument holds true. Zig can be integrated in C projects or any projects that can integrate with C, and you can totally use C in zig projects with minimal friction.
    the argument about people not liking Zig's style boils down to the fact that people prefer the devil they know. C style is nothing to be proud of, it was purely designed as a survival tool. With that said, given enough time, Zig can definitely replace C.
    Currently Zig probably supports more CPU architectures than C does out of the box, it cames with its compiler pre-packaged that can also compile C and C++ files, There is really no reason for new projects to be written in C when Zig is this good.

  6. I think a big thing too is for a lot of cases C is used for, people really wanna know exactly what code is doing, something abstractions, syntactic sugar, features like RAII and automatic destructors go away from

  7. the reason is simple: CPUs and operating systems have co-evolved to be platforms for running C programs.
    Compilers have co-evolved to be optimal code generators for CPUs.
    So the whole bottom half of the programming world speaks in C.

  8. I'm working on a c-variant that does not force any changes at all… it will let you using 100% C code… but it adds the ability to layer things on top… so a true extension of C, and not a replacement… it's opt-in, not forced in.

  9. I like that you organize all this info about this topic, great work.

    However, I do think that saying "C alternatives will never replace C" is naive.
    The way I see it, you can not prove or disprove this statement x) It could happen, and it depends on what developers do. Keep in mind that Zig is also not even 1.0 yet. It is likely to get even better than it currently is.

  10. The reason is much simpler. The C ABI I agree on that is 1 very good reason, but you can still use the C ABI without using C. The real reason is that C has a huge ecosystem of libraries, tooling, jobs, communities and most people that program in C don't want to learn yet another language. C is quietly getting replaced, but by Rust instead.

Leave a Reply

Your email address will not be published. Required fields are marked *

You might like

© 2026 Cantinho do Vídeo - WordPress Video Theme by WPEnjoy