Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning C3

alloc.dev

Post reply on HN
Print view View original

91–100 of 163 posts

Re: Learning C3

#91

Post by lnkl »

lerno wrote: post #83
CyberDildonics wrote: post #49

There was already a better evolution of C called clay. It had templates and ownership. It was C compatible and could be used as a substitute. https://github.com/jckarter/clay/wiki/Clay-for-C---programme...

It might be interesting to note that none of the C alternatives: C3, Zig, Odin, Hare, Jai use ownership nor RAII. Overloading is also generally missing from today's breed of C alternatives. There has certainly been many attempts at C alternatives: eC, Cyclone etc etc

C3 has operator overloading.

Re: Learning C3

#92

Post by lerno »

Daril wrote: post #88

Based on this comparison : https://c3-lang.org/faq/compare-languages/ One would argue that the best C/C++ alternative/evolution language to use would be D. D also has its own cross-platform GUI library and an IDE. I wonder for which reasons D doesn't have a large base adoption.

I can only speak for myself:

1. It is so big.

2. It still largely depends on GC (less important actually)

It keeps adding features, but adding features isn't what makes a language worth using. In fact, that's one of the least attractive things about C++ as well.

So my guess:

1. It betted wrong on GC trying to compete with C++.

2. After failing to get traction, kept adding features to it – which felt a bit like there was some feature that would finally be the killer feature of the language.

3. Not understanding that the added features actually made it less attractive.

4. C++ then left the GC track completely and became a more low level alternative to, at which point D ended up in a weird position: neither high level enough to feel like a high level alternative, nor low level enough to compete with C++.

5. Finally: the fact that it's been around for so long and never taking off makes it even harder for it to take off because it's seen as a has-been.

Maybe Walter Bright should create a curated version of D with only the best features. But given how long it takes to create a language and a mature stdlib, that's WAY easier said than done.

Re: Learning C3

#93

Post by vram22 »

lerno wrote: post #74
tiniuclx wrote: post #11

This looks promising, but I wonder what advantages it has over Rust. Community support is very important for a programming language, and given that this is the first time I am hearing about this project, it still has some way to go. Edit: ABI compatibility & two way interop with C seems to be a pretty big selling point!

Rust is a C++ competitor with all the semantic complexity that comes with it. And similar compile times. C3 is more complex than C (because of a net increase of features), but it's miles from C++ and Rust in complexity and it compiles as fast or faster than C.

How does C3 compared to C in runtime performance?

Re: Learning C3

#94

Post by lerno »

throwawaymaths wrote: post #43

a nitpick: a bit down the page there is stuff on the case syntax. The fact that "you can't have an empty break" is a good choice, but the fact that having two cases do the same thing has syntax case X: case Y: is footgun waiting to happen. I would strongly suggest the authors of C3 make stacking cases look like this: case X, Y:

"case X, Y" works for 3-4 values, but for something longer problems accumulate:

    case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE:
        foo();
        int y = baz();
Placing them on the next row is fairly hard to read

    case SOME_BAD_THING, SOME_OTHER_CONDITION, 
      HERE_IS_NUMBER_THREE, AND_NUMBER_FOUR, AND_NUMBER_FIVE,
      AND_THE_LAST_ONE:
        foo();
        int y = baz();
In C I regularly end up with lists that have 10+ fallthroughs like this, because I prefer complete switches over default for enums at least.

    case SOME_BAD_THING:
    case SOME_OTHER_CONDITION:
    case HERE_IS_NUMBER_THREE:
    case AND_NUMBER_FOUR:
    case AND_NUMBER_FIVE:
    case AND_THE_LAST_ONE:
        foo();
        int y = baz();
I understand the desire to use "case X, Y:" instead, and I did consider it at length, but I found the lack of readability made it impossible. One trade off would have been:

    case SOME_BAD_THING,
    case SOME_OTHER_CONDITION,
    case HERE_IS_NUMBER_THREE,
    case AND_NUMBER_FOUR,
    case AND_NUMBER_FIVE,
    case AND_THE_LAST_ONE:
        foo();
        int y = baz();
But it felt clearer to stick to C syntax, despite the inconsistency.

Re: Learning C3

#95

Post by lerno »

throwawaymaths wrote: post #48
fragmede wrote: post #46

Earlier quoted context omitted.

seems subtle to distinguish between case 3,4: for values 3 or 4, and case (3,4): for an array with the value [3,4]

oof. To me switch/case mentally implies constant time matching and routing, I wonder if that is the case (it could be if arrays have compile-time known length).

You have both in C3:

    switch (x) {
       case 0:
         ...
       case 1 + 1:
         ...
    }
This will behave in the normal way. But you can also have:

    switch {
        case foo() > 0:
          ...
        case bar() + baz() == s:
          ...
    }
In which case it lowers to the corresponding if-else.

Re: Learning C3

#96

Post by lerno »

joshring2 wrote: post #53
aidenn0 wrote: post #36

Anyone know the story behind Huly (which appears to be a company making a web-app mostly in node) sponsoring C3?

As far as I am aware, they support open source as part of their marketing campaign, smart move in my view and helps grass roots projects, Win win.

Yes, just a sponsorship. No other relationship with the project.

Re: Learning C3

#97

Post by lerno »

vram22 wrote: post #93
lerno wrote: post #74

Earlier quoted context omitted.

Rust is a C++ competitor with all the semantic complexity that comes with it. And similar compile times. C3 is more complex than C (because of a net increase of features), but it's miles from C++ and Rust in complexity and it compiles as fast or faster than C.

How does C3 compared to C in runtime performance?

I based the LLVM-IR output on what Clang outputs for C. And so they should be identical. C3 has a single module option for maximum interfunctional optimizations, but Clang can give you LTO for the same thing.

So they should be the same, otherwise it's a bug.

Re: Learning C3

#98

Post by lerno »

lnkl wrote: post #91
lerno wrote: post #83

Earlier quoted context omitted.

It might be interesting to note that none of the C alternatives: C3, Zig, Odin, Hare, Jai use ownership nor RAII. Overloading is also generally missing from today's breed of C alternatives. There has certainly been many attempts at C alternatives: eC, Cyclone etc etc

C3 has operator overloading.

I was talking about function overloading. Sorry for being unclear.

Re: Learning C3

#99

Post by CyberDildonics »

lerno wrote: post #83
CyberDildonics wrote: post #49

There was already a better evolution of C called clay. It had templates and ownership. It was C compatible and could be used as a substitute. https://github.com/jckarter/clay/wiki/Clay-for-C---programme...

It might be interesting to note that none of the C alternatives: C3, Zig, Odin, Hare, Jai use ownership nor RAII. Overloading is also generally missing from today's breed of C alternatives. There has certainly been many attempts at C alternatives: eC, Cyclone etc etc

I think Jai has operator overloading. I won't use any of these though because I can't give up value semantics of data structures. In modern C++ it massively simplifies things and basically makes memory and most resource management a non issue.

Re: Learning C3

#100

Post by dgellow »

Rochus wrote: post #47
90s_dev wrote: post #4

> Don't misunderstand me - I love using foreach in other languages; the added syntax better expresses your intent, reducing logic errors. It did jump out at me as "this isn't C" though. Because it's not. The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself. C++ hides logic in abstractions for the sake of convenience. This is a C++ thing. How does it know how to it…

This is a completely valid and reasonable argument; I don't understand why people are downvoting it.

Because it seems fairly obvious you can use a standard `for` if you need more control over the iteration.
Post reply on HN