RERetro_Dev·Aug 2, 2025Submission
C3 Programming Language 0.7.4 Release
3 points · Open discussionc3lang
c3c
C32020–2026
c3lang / c3c
c3c
Compiler for the C3 language
15Distinct people
31Mentions
0Explicit recommenders
6KGitHub stars
What to know before exploring
What it is
Compiler for the C3 language
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- odin-lang/odin · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:38:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year31 dated mentions
Observed mentions: 2020-08-10 13:27:48 UTC to 2026-09-24 10:33:28 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 12 | 3 | 9 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 10 | 0 | 10 |
What Hacker News says
12 sourcesYou can actually see the whole implementation of `@pool` inside the standard library (link: https://github.com/c3lang/c3c/blob/f082cac762939d9b43f7f7301...) if you're interested. You'll have to follow a few function calls, but the whole implementation is defined within the standard library and thus easily modified for your needs.
I believe that the memory inside the pool is indeed contiguous, and you can ask for a custom initial capacity. The default capacity depends on `env::MEMORY_ENV` at compile-time, but for normal use it's 256kB (256 * 1024, in bytes).
About the explicit allocator passing, that's also a theme throughout the C3 standard library. Functions that need to allocate some memory will take in an `Allocator` as first argument. For those kind of functions there is always a `t<function>` variant which does not take in an allocat
Read the rest
or but calls the regular function with the temporary allocator. It's a nice naming convention used which really helps together with `@pool`. Examples are `String format(Allocator allocator, String fmt, args...)` and `String tformat(String fmt, args...)`.
I hope that clears up some "concerns", and maybe you'll also find some joy in programming in C3 =)
I hope you do know there's a C3 language for a number of years already https://github.com/c3lang/c3c/
In Show HN: The C³ Programming Language version 2Oh `.elements` would you believe that this is a remnant of C2's builtin function `elemsof`? Its used so rarely (I think two uses in the entire stdlib), so it hasn't come up. I opened an issue for it: https://github.com/c3lang/c3c/issues/2130
This is a good example of the sharp edges I hope to smoothen out in 0.7-0.9.
In Odin, a pragmatic C alternative with a Go flavourWell, you're free to revive this issue: https://github.com/c3lang/c3c/issues/1451. I'd need a more solid proposal.
In Show HN: The C3 programming language (C alternative language)I don't have any particularly strong stance on provenance. But I've yet to see a strong argument for it in C.
There is not much of a guide I'm afraid. I translated some of the raylib examples to C3: https://github.com/c3lang/c3c/tree/master/resources/examples...
But those are straight up conversions of the original C code.
I think any C tutorial on gamedev would work fine to follow in C3, and then one can leverage features of C3 as desired.
In Show HN: The C3 programming language (C alternative language)No, there is an incomplete proposal for it here though: https://github.com/c3lang/c3c/issues/1451
What would you like to use it for?
In Show HN: The C3 programming language (C alternative language)For grabbing the CPU features, there is some rudimentary implementation for x86 here: https://github.com/c3lang/c3c/blob/master/lib/std/core/priva... but not properly tested (which is to say, I would not count on it to work properly).
The `@require` here is creating a contract. You can't give a padding that is 0xFF, that's a programming error. However, you might have data which is invalid – in that case the typical error is INVALID_CHARACTER. To pass in a too small buffer is a programming error since the output buffer must be calculated first, so that's why that is not an error either. This was a deliberate change to make the API tighter.
So it's quite possible to add an "INVALID_LENGTH" error, but that should only be there in case one does encryption / decryption where the length cannot be easily determined beforehand i.e. it's part of t
Read the rest
he unknown input which the function determines. But in the Base32 implementation this is not the case. Either use it with an allocator for it to allocate sufficient memory for the data, or calculate that the buffer you pass in is big enough (or run into asserts if it isn't)
Thank you. I am not going to have "fn" stop me from trying out C3 anyways.
There is a C (single header-only) library[1] that determines CPU features at runtime (similar to that of what libsodium does), so I might try to use that with C3 and implement BLAKE2. That might be a good starting point, or perhaps even TOTP, my friend told me implementing TOTP might give me some insight into the language, but for that I will need base32 (I checked, it exists[2]) and SHA{1,256,512}-HMAC, which may not be available in C3, although there may be an OpenSSL binding already, or perhaps I could directly use OpenSSL from C3? The latter would be pretty cool if so.
Regarding the mentioned C library, it might not work, because it is header-only, and it generates the C functions using macros (see line 219). What do you think? Would this work from C3?
[1] http
Read the rest
s://zolk3ri.name/cgit/cpudetect/tree/cpudetect.h
[2] https://github.com/c3lang/c3c/blob/master/lib/std/encoding/b...
---
I checked base32.c3. I am comparing it to Odin's, which can be found at https://github.com/odin-lang/Odin/blob/master/core/encoding/.... Apparently they added a way to gracefully handle error cases. Is it possible to do so with the current C3 implementation?
Edit: I noticed "@require padding < 0xFF : "Invalid padding character"", and there is "encoding::INVALID_CHARACTER", so I presume we can handle some errors or invalid input gracefully. Although I prefer Odin's current implementation because you can handle specific errors, e.g. not just "invalid character", but invalid length (and others, see base32.odin for more). Any thoughts on this?
Additionally, what are the differences between
@require padding < 0xFF : "Invalid padding character"
and
@return? encoding::INVALID_PADDING, encoding::INVALID_CHARACTER
exactly? If I want to handle invalid padding character, I would have to get rid of "@require"?
Additionally, what if there are many more error cases? It would be a "long line" of available error cases? Could I use an enum of errors or something instead or something similar to https://github.com/odin-lang/Odin/blob/master/core/encoding/...?
BTW I like programming by contract, but I am not sure that all error cases that Odin has could have a "@require", and I am not sure if I would like to mix them either, because what if I have a program where I want to handle even "padding < 0xFF" specifically (in terms of base32.c3), or let's say, I don't want it to fail when "padding < 0xFF". Would I really need to implement my own base32 encoding in that case, then, or what?
---
Thank you for your time and help in advance!
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
In Show HN: The C3 programming language (C alternative language)Show HN: The C3 programming language (C alternative language)
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://c3-lang.org/language-overview/examples/ so see how the language looks for some simple examples.
Some other l
Read the rest
inks that might be interesting follows:
I've posted about C3 on HN before, notably
- https://news.ycombinator.com/item?id=24108980
- https://news.ycombinator.com/item?id=27876570
- https://news.ycombinator.com/item?id=32005678
Here are some interviews on C3:
- https://www.youtube.com/watch?v=UC8VDRJqXfc
- https://www.youtube.com/watch?v=9rS8MVZH-vA
Here is a series doing various tasks in C3:
- https://ebn.codeberg.page/programming/c3/c3-file-io/
Some projects:
- Gameboy emulator https://github.com/OdnetninI/Gameboy-Emulator/
- RISCV Bare metal Hello World: https://www.youtube.com/watch?v=0iAJxx6Ok4E
- "Depths of Daemonheim" roguelike https://github.com/TechnicalFowl/7DRL-2025
C3 (a C-like programming language) hits 0.6.6
For people who don't know what C3 is, it's a C-like language which aims to be an evolution on C rather than a whole new language.
With that out of the way:
C3 is continuing monthly releases of 0.6.x. This summer the development of C3 will turn 6 years old. When mentioned as a "new C language alternative", C3 is referred to as a "young" language. Just so that other language creators have an idea how long it takes for a language to get established. For comparison: Jai is almost 11 years in development, Zig 9 years and Rust – finally becoming a mainstream language - started development almost 19 years ago!
By April, version 0.7.0 will be released, removing deprecated code. The plan is to have one "dot one" release each year until 1.0 is reached (and if everything goes according to plan, the version after 0.9 will be 1.0).
For people followin
Read the rest
g C3, this +0.0.1 release had some language changes:
1. Enum conversions starts preferring `MyFoo.from_ordinal(x)` / `foo.ordinal` instead of `(MyFoo)x` and `(int)foo`.
2. Ref arguments for macros are getting phased out to simplify the language, since they can be replaced (although not perfectly) by expression arguments.
3. Allowing the main method to return `void!` is deprecated since it led to rather poor coding practices. This also simplifies the language. Test and benchmark functions get a similar change.
4. Compile time `$foreach` now iterates over string literals, which was missing.
The standard library is also seeing some incremental improvements, including `foreach`-compatible iterators for `HashMap`.
In terms of bug fixes, it sees a fairly large amount of bug fixes, mostly on more obscure parts of the language.
For 0.6.7 compile time mutation of compile time arrays will finally be permitted. And perhaps enums might finally have the missing "enums-with-gaps" resolved (currently, enums are strictly numbered 0 and up).
More importantly though, C3 will see the beginning of work to prune unused features from the language, which will then eventually be removed with 0.7.0.
This will be an ongoing job, to take the still somewhat uneven features of 0.6 and remove anything redundant and unused, as well as making sure that they don't have unnecessary special cases.
Blog post with the full changelog: https://c3.handmade.network/blog/p/8983-another_monthly_release__c3_0.6.6_is_here
Link to the C3 homepage: https://c3-lang.org
Finding it on Github: https://github.com/c3lang/c3c