Show HN: The C3 programming language (C alternative language) • Hacker News Board

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

#51

Post by sfpotter » Thu, Apr 03, 2025, 9:25 PM UTC

lerno wrote: post #18

sfpotter wrote: post #16

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

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.

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

#52

Post by spc476 » Thu, Apr 03, 2025, 9:36 PM UTC

lerno wrote: post #50

owlstuffing wrote: post #47

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

The sometimes annoyingly small differences between platforms.

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

#53

Post by deagle50 » Thu, Apr 03, 2025, 9:51 PM UTC

melon_tusk wrote: post #37

sfpotter wrote: post #16

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

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

#54

Post by lerno » Thu, Apr 03, 2025, 9:53 PM UTC

fuhsnn wrote: post #48

dooglius wrote: 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?

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.

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

#55

Post by unclad5968 » Thu, Apr 03, 2025, 10:29 PM UTC

judofyr wrote: post #39

unclad5968 wrote: post #34

Earlier quoted context omitted.

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.

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

> than to push their language at all cost

Nobody said they do that

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

#56

Post by Asooka » Thu, Apr 03, 2025, 11:20 PM UTC

sfpotter wrote: post #16

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

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

#57

Post by lerno » Fri, Apr 04, 2025, 12:20 AM UTC

WalterBright wrote: post #45

lerno wrote: 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()`?

> `::` 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 no…

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.

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

#58

Post by lerno » Fri, Apr 04, 2025, 12:22 AM UTC

sfpotter wrote: post #51

lerno wrote: 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()`?

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.

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

#59

Post by lerno » Fri, Apr 04, 2025, 12:25 AM UTC

spc476 wrote: post #52

lerno wrote: post #50

Earlier quoted context omitted.

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

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

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

#60

Post by lerno » Fri, Apr 04, 2025, 12:27 AM UTC

Surac wrote: post #32

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