lerno

The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point.

I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.

Yes, I am quite aware. But it doesn’t make D any less a C++ alternative.

It was introduced in 2017, and not part of the original direction of D (it’s neither in 1.0 nor the 2.0 revision of the language)

That D exposes a curated subset of D doesn’t make it a C alternative, even though the ”betterC” aims to target people looking for a C alternative

In any case this seems to be part of some series on Zig, so the title is misleading: it sounds like it’s a blog post talking about memory safety in zig, but it’s just about features in Zig that can make it a little more safe.

What does the AI detection sites say?

Isn't all sorts of stuff metaprogramming in Zig? Generic types, vtable interfaces, printf. All use comptime to generate code.

D was never a C alternative, it was a C++ alternative.

I think the Zig community should worry more about when Jai is released. Esp given that Zig isn’t anywhere near 1.0 yet, and feature wise it’s a rather sparse language that has first mover advantage over alternatives, but as a language it actually doesn’t bring many new tools AND is bad with IDEs.

Jai similarly is hard for IDEs, but has much more depth and power.

While Zig has momentum, it will need to solidify it to become mainstream, or Jai has a good chance of disrupting Zig’s popularity. Basically Zig is Jai but minus A LOT of features, while being more verbose and annoyingly strict about things.

Odin on the other hand has no compile time and in general has different solutions compared to Zig & Jai with its rich set of builtin types and IDE friendliness.

And finally C3 which is for people who want the familiarity of C with improvement but still IDE friendliness with limited metaprogramming. This language is also less of an overlap with Jai than Zig is.

A stack allocator is an allocator that aside from allocate, has a push and a pop function. Image an arena allocator (aka bump allocator), where ”push” stores the current start of free memory, and ”pop” resets to this point, erasing all allocations between push and pop. This is a stack allocator.

It is similar to the function stack, but push and pop can be arbitrarily granular, as opposed to only happening at entry/exit.

No, not alloca, I mean a stack allocator as you push / pop memory scopes.

The trailing body macro is something I think you should try out before dismissing it. It's similar to how Ruby can do it, with the closures exiting the "outer scope", which is unusual.

BTW decimal fixed point or binary fixed point?

In C casting a pointer to an int and back again used to be fine. Except later people want to track the pointer to do optimizations and things went... poorly.

I feel that this is a mess better addressed once there are actual implementations that you have to use, rather than the current state where people are still working out the details.

I haven't used Nim enough to write a good comparison. I am not mentioning Crystal either. If someone wants to contribute a comparison I'd be happy to feature it. It is supposed to be fair and simply outline the differences in features.

I think that one is a bit wrong, I must have written it many years ago. There are machines where pointers do have different address spaces, like the Arduino obviously, but that support isn't in the language yet, and maybe there might be issues there but comparing something like `int` and `float` pointers, that shouldn't be UB. I'll look at that text.

Debug traps can be kept in optimized builds, you can always do something like "-O3 --safe=yes". Right now it's not possible to set it per function or module, but that might be added if there is demand for it.

Because C3 also has contracts, the plan is to step by step increase static analysis to catch more of the contract violations at compile time.

For example:

    <*
     @require a > 10
     @require b < a
    *>
    fn void test(int a, int b) {}

Will error at compile time for `test(5, 2)` (first @require), or `test(5, 10)` (second @require). These will also be checked at runtime, but catching low hanging fruits a compile time will be very helpful I think.

LLVM address and thread sanitizers work. The memory sanitizer still has some issues but will be fixed.

Currently there are just cross platform threads available and some rudimentary thread pools. This needs to be expanded and we'll see if there are things the language could help with but there will not be any async built in.

Well, it's not that difficult to get into the Jai beta if you are building something with Jai I think?

I seem to recall that Jon just asked beta testers that they actually have a project that they will use it for?

Not a C fan then ;)

The temp allocator is a stack allocator, so it's a bit more flexible than that and can be used for return values or even more long lived allocations. It doesn't use the standard heap allocator to alloc, so there is a potential win in speed and cache coherence as well.

For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.

There is an example here: https://c3-lang.org/generic-programming/macros/#trailing-blo... but it's used in the stdlib quite a lot.

Yes both are implemented as attributes `@weak` and `@init` respectively.

Well, you're free to revive this issue: https://github.com/c3lang/c3c/issues/1451. I'd need a more solid proposal.

That one was missing a comma: "I know, it's hard". I'll do my best.

I don't have any particularly strong stance on provenance. But I've yet to see a strong argument for it in C.

There is not much of a guide I'm afraid. I translated some of the raylib examples to C3: https://github.com/c3lang/c3c/tree/master/resources/examples...

But those are straight up conversions of the original C code.

I think any C tutorial on gamedev would work fine to follow in C3, and then one can leverage features of C3 as desired.

Personally I think it is reasonable that a C alternative is an alternative to C, and not a C++ alternative. C3 uses a temp allocator that removes a large number of cases where C++ would need RAII to manage memory. Did you try C3?

You could still do it as a userland feature and implement add/sub/mult/div as methods on the type.

I tried to answer that here: https://c3.handmade.network/blog/p/8886-why_does_c3_use_%252...

No, there is an incomplete proposal for it here though: https://github.com/c3lang/c3c/issues/1451

What would you like to use it for?

I know it’s hard.

You could do

    faultdef
        FOO, // comment
        BAR, // comment
        QUX; // comment

There are third party tools to generate docs. You can also get some json output from the c3 compiler itself to base docs on

Odin isn’t as well known as Zig, true. But what you seemed to argue was that this was a deliberate choice by the Odin community: to look for hype on Hacker News rather than doing the leg work of getting a Wikipedia article about the language.

This idea is what I criticize.

Not to mention that Wikipedia’s notability criteria is increasingly harder to live up to as tech news gets more and more decentralized.

It is not enough for notability that the Odin author is interviewed in various podcasts. It’s not enough for the language to be used in a leading visual effects tool and so on. These are not valid references for Wikipedia.

So how did Vlang achieve it? By commissioning books on the language(!). Once there was a book on V (nevermind no one bought it) it fulfilled the Wikipedia criteria. There are discussions about this on various V forums.

So let go of the idea that Wikipedia is proving anything.

What works for Rust works for Rust. My intent is to make code feel similar to C namespacing. What works and what doesn’t is fairly contextual, depending other language semantics as well.

Destructors and Ownership implies RAII and all the design and architecture that are assumed with such things. This is far from C semantics, and so out of scope for C3.

Any RAII language will be considered a C++ competitor, not a C alternative. None of Zig, Odin, C3 or Hare has RAII.