> Not to shit on decent work, but I don't see a reason to use this over Zig.

Maybe you don't mean to sound harsh but from their About page:

" It is an evolution of C enabling the same paradigms and retaining the same syntax as far as possible."

I don't think Zig has the same goal.

Also, they usefully compare the languages:

"In Zig but not in C3

    Pervasive compile time execution.
    Memory allocation failure is an error.
    Zig's compile time execution is the build system.
    Different syntax and behaviour compared to C.
    Structs define namespace.
    Async primitives built in.

In C3 but not in Zig

    Module system
    Integrated build system
    Built-in strings, maps, vararrays
    Optional contracts
    Familiar C syntax and behaviour
"

> I don't think Zig has the same goal.

It seems to me that the only meaningful difference in their goals, is that C3 wants to stay as close to C as possible, including having familiar syntax.

> Also, they usefully compare the languages [...]

The comparison seems disingenuous.

Zig has a module system where each zig file is a module and it has a mechanism to specify public parts of the module.

One of the standout features of zig is the integrated build system, which uses a reliable caching mechanism to allow incremental builds without rebuilding the world. It's somewhat remniscient of bazel actually.

The zig std library features hashmaps and variable length arrays. Strings are not different from slices of u8. It's unclear to me what C3 means by "built-in strings". The only reference I could find was under "crazy ideas", where they vaguely refer to needing to figure out memory management. That seems like a pretty big outstanding issue for a C competitor.

So the unique feature of C3 appears to be the contracts system of pre- and postconditions, which are only used as language hints to the compiler.

A "module system" should be something beyond a name spacing scheme. So that's the difference.

Re: strings I had a stronger idea of that initially but I wasn't sure, so I kept postponing it, and due to features I added later it's now possible to make strings in userland... probably. I still need to think about this a lot.

But I agree that I should revisit this comparison to make it more up to date. For example an important difference would be that Zig adds quite a bit of UB on top of C, whereas C3 removes UB compared to C.

There are minor things Zig doesn't have like: substructs (I think!), trailing macros (allowing easy "scoping" macros, limited operator overloading (allowing for example userland lists use foreach), type methods are possible to extend by other modules. Then the whole way to do generic types and functions are different, with Zig building it on top of parameterized structs, whereas C3 uses parameterized modules, which creates a bit of difference.

> Zig has a module system where each zig file is a module and it has a mechanism to specify public parts of the module.

"Module system" has many meanings. In functional languages, it has much more flexible semantics than just namespacing and data hiding declarations, so perhaps C3 means it has this sort of module system.

A lot of that latter list seems to actually be in Zig though?

> Funny how we can get stuck with a language from the early 70s and we're still in the process of replacing it half a century later.

I see that as a good thing. I’d much rather have a battle tested framework than everything being rewritten every 5 years in whatever is currently trendy simply because a new generation of developers are suffering from NIH (not invented here) syndrome.

I mean, yes C has its problems so I’m all for using safer languages, but just take a look at the mess that is front end web development and tell me that the alternative isn’t better.

I seriously hope languages like Rust do evolve into being much more than a fad. I’ve been in the industry a fair few years now and have seen languages fall in and out of favour (Pascal, Java, OCaml, Go, etc sure someone of them are still popular but nowhere near as much as when their respective hype machine was in town) and really what systems development really needs is another ‘C’ — as in a language that survives the next 50 years as a standard low level language that people can build solid operating systems from. Whatever language people want to code on top of that base is then fair game.

A language cannot "survive the next 50 years" if people are too hidebound to refuse to let go of the current 50 year old language.

You are asking for the equivalent of those job listings that demand "10+ years experience" in a tech that's only been out for 5.

You’re being rather unfair with your interpretation of my post there. I’ve clearly demonstrated in my writing that I’m in favour of other languages growing. There’s a huuuge gulf of difference between my point about praising platform stability and yours about saying newer languages would never get change to prove themselves. Actually what’s happening right now with Rust being trialed for Linux kernel development, which I’ve acknowledged when I said I hope Rust turns out to be more than a passing fad.

To me this says that C got a lot of things right. I've noticed that even things people complain about, like the somewhat arcane promotion rules to "int" makes perfect sense given the constraints and the expected type sizes. It's not until now that this is somewhat breaking, and that's because with 64 bits `int` didn't follow the normal trend of being register sized.

I would say C3 is closer to Odin than Zig. Given that C3 isn't done yet, I'd personally recommend using Odin over Zig. So there is a clear philosophical difference between the two. Aside of course from Zig departing from C syntax all over.

Zig is in many ways a more ambitious language. Not just in the language itself but in the tooling. Unlike C3 it has the ambition to "do things right" - often by doing things differently. Sometimes that pans out, but sometimes not. For example Zig adds a lot of UB "to be fast", but there's a particularly worrying intersection of (a) UB in overflow, (b) introduction of unsigned overflow and (c) implicit type widening which adds a lot of hidden UB / runtime aborts.

The simple example here is `a : i32 = b + c + d`. Even knowing that b, c and d fits in a short is not sufficient to guarantee this will not have UB. And even if we know that `b + c + d` does not trigger UB, we cannot guarantee that `b + d + c` does not have UB(!). The usual solution it to require explicit widening casts, but that solution seems hard for Zig due to relying on a lot of non-power-of-two types in the core language.

I guess also it's a matter of how much you think C sucks :D

I like C, and C3 is basically just trying to tweak a few things C can't change due to legacy reasons. It doesn't try to be a new "let's write everything from scratch because C is bad" kind of language, if you hate C then C3 isn't for you.

The "inconvenient truth" is that C will never really be replaced, just augmented by "better C" languages, or at most wrapped away under language bindings. Even if Zig's goal is to replace C (which is an important motivation to really cover all use cases of C), I think that most non-trivial real-world projects will actually be mixed C/C++/Zig projects, at least for the next few decades.