Show HN: The C3 programming language (C alternative language)
20 hours ago (github.com)
Get it from here: https://github.com/c3lang/c3c
In 2019, while contributing to the C2 language, I started up "C3" as a pet project while waiting for pull requests to be approved...
Now it's 6 years later and C3 well on its way to 1.0, having released 0.7.0 last week.
Unlike other C alternatives, C3 tries to evolve C – but without concern to backwards compatibility to the latter.
What it adds to C is among other things:
- Module system
- Semantic macros and compile time introspection
- Lightweight generic modules
- Zero overhead errors
- Build-in slices and SIMD types
- Gradual contracts
- Built-in checks in debug mode
You can find more details on the site: https://c3-lang.org It might be interesting to look at the examples: https://github.com/TechnicalFowl/7DRL-2025
One thing I just can't understand is proactively using the :: syntax. It's sooo ugly with so much unnecessary line noise. Just use a single period! I think one of the best decisions D made was to get of -> and :: and just use . for everything.
`::` simplifies the module vs identifier resolution.
In C3 there is something called "path shortening", allowing you to use `foo::bar()` in place of something like `std::baz::foo::bar()`. To do something similar with `.` is problematic, because you don't know where the path ends. Is `foo.baz.bar()` referring to `foo::baz::bar()` or `foo::baz.bar()` or `foo.baz.bar()`?
Sure, but in practice I believe most developers would find it intuitive to just type . everywhere.
It feels more lightweight and consistent, and collisions aren’t super common once you adopt some conventions.
It’s a tradeoff for sure, but this preference comes from having lived in both worlds.
2 replies →
I would just explicit require pulling `foo` into scope, like Rust does. Though in fairness Rust also uses :: for scope anyway and I don't think it's as bad as sfpotter says.
> `::` simplifies the module vs identifier resolution
The identifier on the right is looked up in the scope of the identifier on the left. If it resolves to a module, then it's a module. If it resolves to a function, then it's a function. If the left side is a pointer (not a symbol with a scope) then the right side resolves to a member.
It also makes refactoring much easier - changing a pointer to a reference does not require a global search/replace of -> with .
4 replies →
This is the kind of thing I don't want to have to think about as a programmer. The compiler should just make it work.
1 reply →
I can understand it, I just hate it. I would prefer confusing dots, a module builtin namespace, rebol backslashes, confusing slashes, anything else.
I can live with "this::that", but what drives me bonkers is "this :: that", which is what Odin does. Other than that, Odin is an incredible language.
that's a constant assignment, completely different. And you're not going to see it 100s of times in a project.
I like it. It disambiguates when you're referring to a member of an object -- myobj.member vs referring to a global object by its full name -- module::function. I guess you could say the IDE can colour the two differently, but after spending a lot of time working with various code review tools of varying quality, I have come to really appreciate having the program text be as explicit as possible. If you find it so disagreeable, can't you configure your IDE to visually replace that syntax with a single dot and also automatically convert a single dot to two colons when typing a namespace?
Recently gave this language a spin with raylib and libtmx for loading tiled maps. Out of C3, Zig, and Odin, I've had the least trouble integrating C libraries with C3 (rolled my own bindings for libtmx). Overall a big fan of the language and am hoping it gets recognition on the level of the other languages mentioned here.
@lerno, how do you feel about contributions to the standard library? For example, I might add BLAKE2 if it is not already implemented.
Also I just checked the source code of hash map. What if I want to use a different hashing algorithm for "rehash"?
There is no one true implementation of a hash table either, for example, so I am not sure what to do with that. I want a thread-safe hash table, I wonder if it would ever make it into the standard library.
Blake2 and other hashes are most welcome.
As for HashMap you are completely correct: there are many different types of maps that are needed. Concurrent maps, insertion ordered maps etc. And even variations of the small things: are keys copied or not!
I talked about this on a stream recently, how the standard library is in need of a lot of additional Maps, Sets and Lists.
So if you’re interested in contributing then you’re very welcome to do so.
How does this compare to Zig or Odin, which have the same goals of improving upon C and have gotten occasional publicity here on HN?
As the author, let me add something beyond the comparison. Zig and Odin are very different languages, Odin is – as its slogan goes - "for the Joy of Programming". Zig on the other hand doesn't feel that this is a goal. From what I can tell Zig fans like to wrestle with the features of Zig to figure out how to fit their solutions within the constraints of the language. A mental challenge, similar to that of fighting the borrow checker in Rust. People who "figured out" Zig tend to be fiercely loyal to the language in a similar way as Rust evangelists to Rust.
C3 has a lot in common with Odin, but very little in common with Zig.
C3 has a slightly different feature set than Odin (e.g. more compile time execution, has methods, contracts, but doesn't have Odin's matrix programming and more extensive runtime reflection), but the goals aligns strongly with Odin's.
If you prefer C syntax and semantics you might like C3 better, but Odin is a fine language too.
On ziglang.org the very first thing we advertise is:
> Focus on debugging your application rather than debugging your programming language knowledge.
Clearly, you think the language fails at this criteria (your subjective opinion). Please be honest and say that, rather than implying that it's not explicitly one of the core design principles of the language (objectively false).
Just to be clear, I don't mean the description of Zig to put down the language or the community. It's the best I can do to describe the difference between Zig on one hand and Odin/C3 on the other.
A more concrete example that might explain it better is looking at Advent of Code solutions.
One thing that struck me was that doing typical tasks for parsing would be 2-3 functions stringed together in a smart way in the Zig solutions, whereas in Odin and C3 it was achieved by having a single standard library function that did these steps.
From what I understand, there is a pushback against creating convenience functions in the Zig standard library, if the same thing can be achieved by stacking together a few functions.
My understanding is that doing these smart things with the Zig library with the existing functionality of considered a cool way to leverage existing code.
In C3, and I feel Odin as well, the lack of such a convenience function would be considered an omission to patch, and that having to stack things together should be reserved for specialized solutions, rather than having to stack things together for everyday tasks.
Thus in C3 and Odin, it is okay to trade detailed explicitness for convenience, whereas this is a no-no in Zig.
But what this means is that Zig users tend to celebrate and focus on smart and clever code, whereas this is a complete non-goal in C3 and Odin.
I could probably have formulated this better before.
> People who "figured out" Zig tend to be fiercely loyal to the language in a similar way as Rust evangelists to Rust.
This is very much not productive and you’re now part of spreding this narrative. There’s plenty of people out there who has «figured out» and appreciate both Zig and Rust without becoming attached to it.
I’m interested in communities which looks towards other languages for inspiration and admiration, not judgements and alienation.
11 replies →
Zig and Odin compiler may implicitly pass variables by references[1][2], creating hidden aliasing, that's one thing unacceptable for me coming from C, I haven't read about C3 doing this, hopefully it doesn't and not planned in the future.
[1] https://www.1a-insec.net/blog/25-zig-reference-semantics/ [2] https://github.com/odin-lang/Odin/issues/2971
C3 follows the C ABI, so no it doesn't do it and it's not planned.
For one thing, C3 thankfully understands that there are more mathemathical types people are interested in than just ints and reals, for example vectors: https://c3-lang.org/language-common/vectors/
Zig has SIMD vectors, but I frequently need 3D vectors, and refuse to use things like vec3_add(vec3_mul(a, 2), b) etc since I mainly develop 3D graphics software.
interesting example of swizzling
``` int[<3>] a = { 11, 22, 33 }; int[<4>] b = a.xxzx; ```
I assume that the `xxzx` is translated directly by the compiler. not seen that in any other language though ruby can fake it pretty easily via `method_missing`
2 replies →
It is answered here: https://c3-lang.org/faq/compare-languages/
I feel like its missing a point for "In C3 but not in Jai": you can actually download and use C3...
tbh I think one of the things I really liked reading through examples was the change in the switch/case behavior. I always thought implicitly falling into the next case was an awful design, and that a break is the more logical implicit behavior except in the case (no pun intended) of stacked empty case statements.
I do all my coding in Python, but if I ever find myself needing to reach for C again, I'll certainly consider this.
EDIT: Though is there a reason why "fn" is needed? I would think the AST builder would still be able to identify the beginning of a function definition without it, and as a programmer, I can identify a function definition easily.
Things like that make grepping easier. And redundancy of syntax makes reading-without-mistake faster. The more you put on the page the lower the cognitive load, the more spare it has in it, the easier it is to search for increasingly refined contexts of use.
Agreed. It's tempting to make the tersest lang you can but in the end what matters is ease of reading.
For ex. parens-less calls (myfunc 42 "hello") are elegant but don't stand out and - for me - take more time to identify.
Also `fun foo(i:int)` is easier on the parser than C-style `void foo(int i)`
2 replies →
I wrote a short blogpost about this before, trying to answer the question: https://c3.handmade.network/blog/p/8886-why_does_c3_use_%252...
Does it allow you to make functions weak? Can you do something like gcc's constructor attribute?
Oh. This actually looks like something I could see myself using, maybe. I thought I'd hate it, but after checking out the examples, this is pretty nice.
There are some syntax choices that aren't ones I'd have made (eg I prefer `ident: Type` and types being uppercase, I don't like `fn type identifier ()` for functions etc), but coming from C, I can see how and why it ended up like it did, and overall this looks really good. Great work!
I have used this language for a few things (csv parsing and some simple personal cli tools). Other than the normal pre-1.0 issues it's great. I wish it had a tagged union type, but it looks like that's planned based on the github issue tracker.
It is a pretty big improvement on C without changing the ABI. Maybe not the improvements I would make if I was smart enough to make a compiler, but better than doing C which I also enjoy despite it's warts.
Are there any examples of using a C library (binding, FFI) in C3? A quick search came up empty.
Did you see this? https://c3-lang.org/language-common/cinterop/
Oops, I missed that, thank you! Seems straightforward. I will give it a spin later. :)
Here you go: https://ebn.codeberg.page/programming/c3/c3-opengl/ This one is for OpenGL.
Overall, this is one of the better C killers I’ve seen. But keeping macros while ditching conditional compilation? That seems completely backward to me. Oh well.
What kind of conditional compilation are you missing?
For adapting code to different versions of libraries for one thing:
The sometimes annoyingly small differences between platforms.
3 replies →
Hello, your doc about const says "The const qualifier is only retained for actual constant variables".
Then how do you express read-only pointers ? Like C `const int* ptr`
If you pass them as parameters, then there are in/out/inout annotations to limit usage. But other than that, there isn't anything.
So many of the so-called "C alternatives" end up doing way too much. I don't need algebraic data types or classes or an integrated build system or a package manager.
What I would like to see is a language that is essentially just C with the major design flaws fixed. Remove the implicit casting and obscure integer promotions. Make spiral rule hold everywhere instead of being able to put const at the beginning of the declaration. Make `sizeof()` return a signed type. Don't allow mixed signed/unsigned arithmetic. Make variables/functions private by default i.e. add `public` to make public instead of `static` to make private.
Keep the preprocessor and for the love of god make it easy to invoke the compiler/linker directly so I can write my own Makefile.
There is no spiral rule, that is a misconception. Look up how "declaration follows usage" in C. E.g. https://eigenstate.org/notes/c-decl
While this rule has become somewhat diluted when C developed and gradually took on features from C++ (like types in function parameters), it's still very helpful to understand the guiding principle. (But those inconsistencies that crept in over time are also the reason why newer languages don't do that anymore).
Arguably, what you describe, is closer to what C2 was/is[1]. By the way, C2 is still alive, for those that care to look.
C3 (link[2]) is a fork of/inspired by C2, which appears to have incorporated a lot of Odin and Jai "flavoring". In the case of both C3 and Odin, it can be argued that part of their popularity is that Jai isn't publicly released. Consequently, they seem to pull in a lot of the crowd, that would be attracted to Jai. Another aspect of this, is the more C3 promotes itself (whether intentional or not), the more likely C2 will get faded out. Many will likely think C3 is the next iteration of C2 or simply know the name more, because pushed on HN and other social media.
[1] https://github.com/c2lang/c2compiler
[2] https://github.com/c3lang/c3c
Isn’t it a somewhat unfair characterization that ”C3 promotes itself more” and ”is pushed on HN and other social media” and that because of this C2 for some reason experiences harm?
C2 is over 11 years now. C3’s recent breakthrough this last half year is unlikely to have had much impact on its ability to grow the last 10 years.
as much as i like a better 'C' language, it is hard to use them. so many things have been done in C and you find everything in the net you would ever like to use. Using a better 'C' places you on that strange island where no one hears you cry. Using C3 in a company places you in a place where only you can understand the code.
Yes, this is a very real problem that I've also written about: https://c3.handmade.network/blog/p/8486-the_case_against_a_c...
Does C3's compiler utilise the highly optimized C compilers like clang and gcc similar to Vlang and Nim?
it uses LLVM, see the bottom of TFA
It uses llvm.
Any other C alternative or C-like languages that people here are using more than experimentally?
Asking because my above question and this current post about C3 are related to this recent post by me, which had a good number of comments:
Ask HN: What less-popular systems programming language are you using?
https://news.ycombinator.com/item?id=43223162
Other than C3, there is Jai, Odin, Zig and Hare which are the ones that have any traction right now that I know of. Many interesting projects have been started but ultimately later abandoned.
Going to C++ competitors there is obviously Rust, but also Nim, Crystal, Beef and a lot of others. (And Jai is a C++ competitor too)
[dead]
[dead]
[dead]
Programming language dev is quite common. I've been cataloging various languages on r/altprog on Reddit. This particular one seems to have influences from several other languages (quite a few use "fn" for function declaration, plus there's a module system).