Live data from Hacker News

Show HN: The C3 programming language (C alternative language)

github.com

21–30 of 192 posts

Re: Show HN: The C3 programming language (C alternative language)

#21
post #18

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.

Re: Show HN: The C3 programming language (C alternative language)

#22
post #5

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.

Re: Show HN: The C3 programming language (C alternative language)

#23

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 con…

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...

Re: Show HN: The C3 programming language (C alternative language)

#24

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 con…

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)`

Re: Show HN: The C3 programming language (C alternative language)

#26
post #22
post #5

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 t…

> 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.

Re: Show HN: The C3 programming language (C alternative language)

#27
post #25

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. :)

Re: Show HN: The C3 programming language (C alternative language)

#29
post #18

Earlier quoted context omitted.

`::` 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.

N=1; I find :: a lot more obvious.

Re: Show HN: The C3 programming language (C alternative language)

#30
post #18

Earlier quoted context omitted.

`::` 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 ::.
Post reply on HN