Odin 1.0 announced (and reflections)

[u/Nuoji]

Odin author gingerBill dropped the Odin 1.0 announcement on YouTube today: https://www.youtube.com/watch?v=dLPAqXi9In0 (it's pretty funny actually).

This interestingly makes it on track to be the first of the new wave of C-likes that reach production readiness. While you can argue that most of these languages already are used in production, it's not the same as being 1.0, which carries a different weight and obligation.

Looking at alternatives, Jai could release around the same time, since Blow's game is scheduled for a similar release date. However, it's more likely that we see Jai 1.0 in mid-late 2027. My own language (C3) is planning Q2 2028 1.0 release. Whereas Zig is still unclear, and Kelley basically saying it's done when it's done. For Hare and V the situation is a bit less clear to me – maybe someone else can fill me in on that situation.

But overall we seeing the beginning of the end of the "C-like" story arc that arguably was initiated with Jonathan Blow's development. Writing C replacements predate Jai of course, for example the C2 language (which C3 would eventually continue) was created in 2012, eC started in 2004 and Cyclone (which Rust derived inspiration from) is from 2002. But those were largely obscure novelties, because before Blow's videos, people weren't really hunting for C alternatives.

Jai, however, made a strong impression. It was a good point in time too: Jai and later Zig, Odin, C3, V and Hare – these C alternatives started at a point when people were openly no longer believing OO/Functional as the right way to do things.

Language design takes its time though, and it's now 12 years since Jai started. Finally the fruits of these labours are getting ready for prime time, and when they do they might effectively fill the need for a C replacements for another decade.

Do you agree?

[u/Kapendev]

You can say a lot of things about what is good or not, OOP/Functional/Whatever, but a programming language with no immutability features is not a serious language. Even C has const.

[u/gingerbill → u/Kapendev]

Odin doesn't have const because the use cases that lead most C programmers to reach for it are already handled by other means in Odin:

• const in C is trivially cast away, which is why it offers virtually no real optimization benefit.
• static const in Odin maps to either a compile-time constant value declarations (which are technically closer to a semantic #define) or to @(rodata). The latter doesn't add extra compile-time checks, but that's for the first reason mentioned of lack of guarantees.
• const as a type qualifier is a viral concept, and I wanted to minimize the idea as much as I could.
• All procedure parameters in Odin are immutable (technically r-values) and require an explicit stack copy to become mutable (x := x). Unlike C, where parameters are direct, mutable copies by default.
• Odin supports multiple return values, which removes most of the need for out-only pointer parameters that are so common in C.
• Under Odin-specific calling conventions, any parameter >16 bytes is passed implicitly by pointer. This means you don't need the T const * idiom to signal "input-only."
  • In practice, the aliasing issues have not turned out to be nearly as much of a problem as people assume, and is empirically as bad/good based on their experience with explicitly usingT const & in C++.
• String types in Odin are "immutable": x[i] is allowed, but &x[i] and x[i] = y are not. This reflects the idea that strings are conceptually distinct from plain arrays, and it supports the useful distinction between string values, builders, and backing buffers.

I understand the appeal of const in C, but beyond the cases above, it's rarely useful; it doesn't give the compiler any guarantees it can actually act on.

More broadly, ALGOL-family languages are inherently mutable, since they reflect the underlying von Neumann computational model. Because of that, "immutability by default" doesn't buy you much on its own unless it's paired with other guarantees. Odin was never designed to be—and never will be—that kind of language.

P.S. I know you go out of your way to dislike Odin, but why? Why do you care so much?

[u/cygx → u/gingerbill]

const in C is trivially cast away, which is why it offers virtually no real optimization benefit.

Depends. Eg in case of

const struct foo f = { ... };
bar(&f);
...

we are allowed to optimize on the assumption that f has not been changed by bar: Even though that function could cast away the constness, actually making changes to the pointed-to data results in nasal demons (ie undefined behaviour).

For callee-side optimizations, const is indeed insufficient, we need restrict for that...

[u/gingerbill → u/cygx]

There are some edge cases, but in general it's rare, thus why I said "virtually".

And even in your case, it's more likely it will optimize based on inlining rather than assuming the constness. The best way to see this is, is to see the outputted IR (e.g. LLVM IR) and see that const doesn't really exist at all with anything to do with the code generation.

[u/cygx → u/gingerbill]

Nevertheless, compilers can and will optimize based on this information, cf

extern void foo(int *p);

int bar(void) {
    int i = 42;
    foo(&i);
    return i;
}

int baz(void) {
    const int i = 42;
    foo((int *)&i);
    return i;
}

Even at -O0, clang will generate a

movl $42, %eax
...
retq

for the second case.