Learning C3

It's an interesting problem. Originally I experimented with both having `` and `&` syntax, so `int&` being a ref (non null) and `int` being a pointer. The thing you notice then are two things:

1. You want almost all pointer parameters non null.

2. Non-null variables is very hard to fit in a language without constructors.

Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned.

It's certainly possible to create generic "type safe" non-null types in C3, but they are not baked into the language.

Nim solves this problem by only having two explicit, restricted nullable types: Pointers and references. Pointers are manually managed, references are automatically managed, both start as nil and must have their referenced objects instantiated manually.

The entire rest of the language is built on pass-by-value using stack values and stack-managed hidden unique pointers. You basically never actually need to use a ref or a pointer unless you're building an interface to a C or C++ library. I having written a 40k line production application with no reference or pointer types anywhere. Almost any case you'd need is covered by simply passing a compound type or dynamic container as a mutable value, where it's impossible to perform any kind of pointer or reference semantics on it. The lifetime is already managed, so semantically it's just a value.

I'm on the fence about function contracts like this. I've seen them for a decade in other languages, but never really used them, so I can't say how I feel about them.

But having them be inside comments is just weird.

There's also C4, but that's either an explosive or a notation language for modeling software architecture.

Yes, C3 started as a variant of C2.

Problem with Hare is that it is (or at least was last time I checked) Linux/Unix only and so by design. That kinda makes it DOA for many.

There's also Zig in the C-alternatives space.

https://ziglang.org/

It was the minimal change from C. It's fairly easy regex out the types, so while not as nice as Odin, it should be straightforward.

Named parameters are already in the language.

Regarding concurrency, I don't want to pick a single concurrency model over another. I will see what hooks I can make for userland additions, but the language will not be opinionated about concurrency.

C3 error handling is fairly novel though. It tries to find a sweet spot between composability, explicitness and C compatibility.

The try-catch has nice composability:

    try {
        int x = foo_may_fail();
        int y = bar_may_fail(x);
    } catch (... ) {
        ...
    }

    int? x = foo_may_fail();
    int? y = bar_may_fail(x);
    if (catch err = y) {
       ...
       return;
    }
    // y is implicitly unwrapped to "int" here

"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();

    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();

    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();
  

    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();

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]

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.

Is Zig really that common at this point that you'd feel comfortable using it for a work project? Its not just going to piss off the next person and have them need to rewrite it? I guess Rust has the same problem to some extent but there is a lot of resources for writing Rust out there now

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.

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 could easily change a C for loop to use i += 2 instead of i++ if I wanted, that's the beauty of it.

If you're not doing something for each element of a collection, you should not be using a `foreach` loop. In exchange for not exposing the implementation, you immediately know the behavior. You also don't have to worry about checking the rest of the loop body for later mutations.

> The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself.

Given the widespread undefined behavior and the ways that compilers aggressively rely on that to reorganize and optimize your code, that hasn't been the case for many many years.

Sure, if you're using dmr's compiler on a PDP-11, then C is a pretty transparent layer over assembly, which is itself a fairly thin layer over the CPU. But today, C is an ambiguous high level communication language for a highly optimizing compiler which in turn produces output consumed by deep pipeline CPUs that freely reschedule the generated instructions.

It uses operator overloading of [] &[] and "len" to create a straight for loop. Normal C for loops are there of course.

Just curious - in what situations would you want to use `foreach` (with the intent to iterate over a sequence), but use `i += 2` instead of `i++`? I can only think of a situation where I want to group elements by pairs, but then I'm explicitly not doing a "for each", and would prefer to explicitly use a regular `for`.

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

I would prefer a "lightweight" C++.

C++ is fine, but it's insanely slow to compile.

I generally like C++, but I could trade anything to make it faster to compile, and most of the time, I just use a small subset of C++ that I feel okay with.

C3 benefits from focusing more on the problem at hand than language complexities.

There are definitely advantages to simpler tools, you can streamline development and make people more productive quicker. Compare that scenario to C++ where you first have to agree the features you're allowing and then have to police that subset throughout on every PR.

Is for the C++ without Classes crowd, mostly.

Personally when I initially learned C++ back in 1993, with Turbo C++ 1.0 for MS-DOS, I hardly saw a reason to further use C instead C++, other than being required to do so.

C3 is "mostly C++" in the same way that my bicycle is "mostly a motorbike".

the problem with picking C++ is that eventually you onboard someone who uses the warts in their code, and then the warts become like craft glitter.

To me it didn't really feel like C++; it is much less complicated. Could you explain more what you mean by this?

I want to second this comment.

The comparison shouldn't be with C, it should be with C++, Rust, or Zig.

The place to go is actually the C3 comparison page:

https://c3-lang.org/faq/compare-languages/

There you can see that there are very few items "in C3 but not Rust", for example. Mainly "it's a familiar C-like language".

I am also suspicious of the macro system. I'd like more of an explanation of how it works. Especially how it relates to Zig comptime, and whether it has "hygiene" problems. Hygiene to me means: can a variable name in a macro expansion refer to a variable outside of the macro? (The concern is that this could be accidental.)

https://c3-lang.org/generic-programming/macros/

Rust is way more complex to say the least, in fact it's the sole reason why it still has the same market share as COBOL(https://www.tiobe.com/tiobe-index/). Rust 1.0 was released 10 years ago by the way.

Community support in C3 is massive, as you can use C libraries directly, it might parallel or exceed Rust on that metric, and the barrier to adding native C3 wrappers or versions is significantly lower too.

Rust is solving a different problem, that of safety over all else. C3 on the other hand is more akin to developer experience above all else.

If you find something that should be easier to do in C3, that's a bug.

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.