Show HN: The C3 programming language reaches feature-stabiliy
C3, "The C-like for people who like C" just reached v0.5, marking its feature-stable release: https://c3.handmade.network/blog/p/8824-say_hello_to_c3_0.5
Feature stability ensures that version 0.5 will undergo bug fixes and maintenance separately from the main branch, providing projects with a stable compiler version to work with.
Try it out in the browser https://learn-c3.org
Github: https://github.com/c3lang/c3c
If you appreciate C, then maybe this is a language you'll enjoy. Dive into the documentation at https://c3-lang.org to view examples and read more in depth about the language.
7 comments
[ 2.9 ms ] story [ 29.0 ms ] threadOk, so old folks still use C, but we have come a long way since the seventies gramps!
Why would anyone do a C clone?? This is not worth even looking at, a waste of people’s time.
Try Zig instead or maybe Rust (I haven’t tried it)
Also C3 is not a clone of C, it is an evolution, where the syntax is kept similar.
Saying that the syntax is not intuitive is a subjective topic, a lot of people (myself included) find C syntax much more intuitive than newer languages.
About Zig, I haven't tested it yet, but I want to experiment with it when I have time. And about Rust, I tried it, and, at least to me, it is even more confusing.
Anyway, I like to encourage people to try different languages, even if you go back to a classic or a newer one, the experience obtained thinking different for the problems, or even developing the language to tackle those problems is invaluable.
fn void Stack.push() ? really? why did anyone thing "fn" in front of a procedure/function makes sense in a C language family?
Like saying Hi-hello, sir
Originally C3 was merely an extension of C2 - which was largely a streamlined C syntax + modules + struct methods. BUT C2 introduced `func` as a function prefix, plus `type Foo struct { ... }` for type declarations to simplify parsing.
So C3 inherited that, but scaled back on the divergence from C, making struct declarations the more familiar `struct Foo { ... }`. The `func` felt too heavy, so it was later reduced to `fn`.
But couldn't that "fn" also be removed? It seemed as if the grammar would allow that while keeping the grammar simple.
However, there were arguments against:
(1) `fn` was also used as a keyword for defining lambdas and function pointers in a straightforward way.
(2) it is symmetric with macro definition: `macro int foo(x) { ... }` and `fn int foo(x) { ... }`
(3) it makes it trivial to search for functions using regex or even plain text search.
While some people wanted it removed, there were a lot more who argued for keeping it esp for that last reason.
I don't really have a personal preference, but it is helpful to keep some additional simplification to the grammar to allow further modifications or additions.
To me, personally, the obsession for cryptic acronyms and mangled words is a relic of the '60ies which could need an update. It was motivated by limited RAM and CPU time for the compilers, it was never the right choice but a necessary cut. It should have ended in the '90ies. Redundant words fall in a similar category, as something looking smart now and being the reason for further criticism as they are discovered to be nothing more than dummy stubs to simplify one specific tool/task.
Java and JS showed you can have a language with keywords written in correct English (ok, except for enum) and still be part of the extended C family.
It's frankly surprising how shockingly ugly is a modern language like Rust, where literally not a single keyword is written properly. Dyslexic by design, yet requiring vast amount of resources to parse/compile.
It can be fun while it's the underdog language, but as it gains prominence, it will just flood the world with weird syllables and strings which is too late to fix. Until the next language takes over.
I hope you understand why I'd rather avoid having a new and promising language go down the same path.
I am not suggesting any modification, I respect your code, your way of thinking, your effort to create something new. I'd however like to share my concerns as constructive criticism