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.
I like to quickly at a glance be able to distinguish between "this is a member access on an object" and "this is referencing something in a module".
I like that the compiler can distinguish those two things too, so that I can refer to things within modules even if I happen to also have a local variable with the same name. Go sometimes annoys me because I need to rename a module or a variable just because the syntax doesn't distinguish between the two things.
`::` 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.
I’ve lived in both and I prefer ::.
I prefer a world where there is no distinction between modules (or namespaces) and object, so '.' it is. (and I'm almost exclusively a C++ programmer).
N=1; I find :: a lot more obvious.
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 .
C3 has "path shortening", so for example given `open(...)` in std::io::file is usually used as `file::open(...)`. If we would to write this as `file.open(...)`. Consider now the case of mistyping `open`: `file.openn(...)`. Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope?
Also, "io", "file", "random" etc are commonly used variables, so the issue with shadowing is real.
`File file = file::open(...)` is completely unambiguous and fine. `File file = file.open(...)` on the other hand would be bad.
If the language had flat modules, or no path shortening, then it would be possible.
I feel like path shortening is the issue, and IMO it's an unnecessary feature. I don't think most programmers are bothered by the need to explicitly import what they use. I'd personally prefer to explicitly import what I use, and refer to it in whatever way the import statement would imply.
In Rust where modules share a namespace with other identifiers, I just pick different variable names, or write my imports so they don't conflict. It's not that big a deal.
> Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope?
D uses a spell checker for undefined identifiers, and the dictionary is all the identifiers in scope. It has about a 50% success rate in guessing which identifier was meant, which is quite good.
> Also, "io", "file", "random" etc are commonly used variables, so the issue with shadowing is real.
If the same identifier is accessible through multiple lookup paths, an error is issued. If a local variable shadows a variable in an outer scope, and error is issued.
We've developed this over several years, and it works quite well.
Path shortening can be done with:
alias open = file.open;
import io: open;If I would have liked, I could have done something like `import std::io::file as file;` but I noticed that we keep getting this issue that we’re renaming things all of the time, and usually in the same way. This is why path shortening is there. To directly get something like the informal `file_open` namespacing in C programs.
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.
But you have to. Ambiguities hint at lack of redundancies that also affects code reading. When you quickly scan something like `file.open` vs `file::open` the former is also more unclear to a reader without more context.
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.
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.
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.
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).
(Funny story, I seem to have a bout of visual migraine at the moment and misread your comment until just now and had to remove what I wrote).
I didn't mean to give the impression that I'm putting down Zig. It's more that I've noticed that people tend to frame problems differently with Zig than with Odin.
To explain what I mean by framing, consider OO vs procedural and the way OO will frame the problem as objects with behaviour that interact, and procedural will frame the problem as functions being invoked mutating data.
The difference isn't at all that stark between Odin and Zig, but it's present nonetheless. And clearly Zig is doing something which a lot of people like enjoy. It's just that the person using Zig seems to enjoy different aspects of programming (and it seems to me be in the spirit of "the challenge of finding an optimal solution") than the person using Odin.
> 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.
For what it's worth, I found the Zig community on the biggest Zig discord very nice and welcoming. But that said, there is a lot of "you have to understand Zig" sentiment. Also, there is a lot of "I discovered Zig and it's finally showing me how to program" echoed as well.
I don't find this an unfair judgment but rather an observation.
I think this naturally arises from the language claiming to be "a programming language designed for robustness, optimality, and clarity" (See for instance https://www.recurse.com/events/localhost-andrew-kelley)
If you feel that this is an optimal programming language that gives more robustness and clarity than other languages, then it's natural to be preachy about it.
This is similar to Rust being sold as safe language, where similarly the proponents of Rust feel that the advantages of Rust need to be spread.
As a contrast, Odin focuses on "joy of programming" as its main goal, and the author does not make any claims of the language having killer features to choose it over something else.
However, it seems to be successful in that new users tend to remark how pleasant and fun it is to program in the language.
Off-topic (maybe should ask elsewhere), but why is C3 using "fn", it could not be avoided?
Edit: Someone already asked: https://news.ycombinator.com/item?id=43572190
This is a good point about narrative spreading, in addition to marketing. People can become evangelized by their use of certain languages or by comments from certain language creators, then go on to attack others for using or even just wanting to try other languages. This shouldn't be what HN is about. It makes it look like HN has a language approval list.
As for both C3 and Odin, they've been around for many years, yet don't even have a Wikipedia page and have relatively low numbers on GitHub. That comes across as more time spent pushing or hyping on HN, than those languages being considered a truly viable alternative by the general public. Just weird, because you would think it should be the other way around.
Did you know that Wikipedia editors will aggressively remove Wiki entries about less known languages. There are already several wiki articles on Odin by various authors that have been removed over the years.
Talking about GitHub numbers, we can look at VLang, which had an astronomical trajectory initially due to overpromising and selling a language that would solve long standing issues such as no manual memory management but no GC needed etc.
Such viral popularity creates a different trajectory from organically growing word of mouth such as in the Odin case.
Vlang also has a Wikipedia page.
Is this then proof that it is a viable alternative to the general public? This is what you argue.
I don't think I'd use popularity-contests like Github stars or the presence of a Wikipedia page to judge a language's popularity or future prospects.
So which language do you use then? I've never seen a language that doesn't have bad things to say about other languages. Zig bdfl himself accused vlang of committing fraud a while back.
Every language designer takes things they like about some languages and leaves things they don't like.
The accusation is harsh, but I think Zig's BDFL had a point. V-lang seems to have been poorly led for many years.
https://news.ycombinator.com/item?id=27441848
https://news.ycombinator.com/item?id=39503446
Many links paint a picture of constant false advertising, even deception.
> I've never seen a language that doesn't have bad things to say about other languages.
That's why I said "communities" and not "languages". Every programming language has a wide set of people who use it. You can always find some people who constantly say bad things about other languages. You can also find people who are interested in the different trade offs of the language. I use languages which are technically interesting, and then I engage with the parts of the community which are interested in finding the best solutions to actual problems.
And guess what? Most of the Zig and Rust community are, in my experience, way more focused on solving real problems than to push their language at all cost. Both /r/rust and /r/zig will often recommend different languages. I mean, this was the most upvoted comment around how to convince someone's boss to use Rust over Python: https://old.reddit.com/r/rust/comments/14a7vgo/how_to_convin....
> than to push their language at all cost
Nobody said they do that
> Zig bdfl himself accused vlang of committing fraud a while back.
I think there's a difference between a critical generalization of a community and the mindset behind it and how that relates to the language (without weighing in on how legitimate that criticism is), and a direct accusation that one individual did a specific bad thing.
> Zig bdfl himself accused vlang of committing fraud a while back.
That was truly foul. On top of that, begged readers to give their money to Zig. Clearly some have no limits on what to say and do against other languages or to sell their language.
That's why whatever bad things a creator or evangelist says about another language, people shouldn't just swallow, and instead take with a grain of salt and some skepticism.
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`
This is not that novel. It is inspired by the similar feature in the Odin language.
ah, neat if it's becoming a standard convention of sorts. i haven't used odin either.
It's a good language, you should try it out as well.
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)`
I prefer lack of "fun" and "fn", to me it is easier to parse C-style. :( This is one of the things (albeit minor) that put me off of C alternatives, I like to keep things as simple as possible, but I understand it has "macro" as well, so might as well have "fn", for the reasons already mentioned.
That said, I will still try C3.
Also, `fn` is used to make type inference for lambdas syntactically simple. But I would lie if I said I haven’t been considering removing `fn` many times. But there are good reasons for keeping it, despite the break with C.
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...
@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.
> And even variations of the small things: are keys copied or not!
Yeah, or if duplicates are allowed or not, initial size, load factor, and so forth.
Does it have native fixed point types?
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.
Making compilers are not that hard. Sure, it grows in complexity as you make it more feature-complete. But writing compilers is actually a lot of fun. If you're interested in compilers you should definitely try making a simple one. This book is free and a great starting point: https://craftinginterpreters.com/. I'm not associates with the book author in any way, I just found incredible value in it.
Does it allow you to make functions weak? Can you do something like gcc's constructor attribute?
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:
#if defined(__SunOS)
presult = getprotobyname_r(proto,&result,tmp,sizeof(tmp));
if (presult == NULL)
return luaL_error(L,"protocol: %s",strerror(errno));
#elif defined(__linux__)
if (getprotobyname_r(proto,&result,tmp,sizeof(tmp),&presult) != 0)
return luaL_error(L,"protocol: %s",strerror(errno));
#else
presult = getprotobyname(proto);
if (presult == NULL)
return luaL_error(L,"protocol: %s",strerror(errno));
result = *presult;
#endif
Oh, I think you missed something then:
There is both `$if` and `$switch` compile time statements for this: https://c3-lang.org/generic-programming/compiletime/#if-and-...
At the top level and `@if` attribute is used to achieve the same thing: https://c3-lang.org/language-common/attributes/#if
Ah. The top-level lang description claims “No preprocessor”, but my definition of that word doesn’t appear to be the same as yours :/
The difference here is that a preprocessor runs before parsing and semantic analysis. In C3 compile time if runs in the analysis step, so after parsing.
So the macros and compile time execution occurs after parsing in C3, but in C everything happens at lexing, before the code is parsed.
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.
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?
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)