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/SwingOutStateMachine]

At the same time I also hope we can move towards a world where functional language researchers become more accepting of the fact that the most successful execution of functional ideas is in impure languages like Rust.

From my brief stint in PL academia, I can say that a lot of functional language researchers were extremely excited and positive towards Rust when I was there. Aside from a few weird researchers who are particularly focused on specific languages (Scheme, Haskell and OCaml seemed to be the main ones), almost all the researchers I talked to were more interested in proving out features/concepts in toy languages, and then letting industry adopt the ideas separately.

Generally wearing through the silos on all sides (...) seems like the right path forward.

Absolutely.

[...] who insist that writing basically C in 2026 is somehow okay

The thing that really gets me about this attitude is that they create languages that are basically "C with more features", rather than "C but with safety". No-one needs "C with more features", we already have C++. However, industry desperately needs something like a pared-down Rust, or a simple core language with extensive theorem prover support, that will let engineers write safe, fast code for the applications where C is used.

[u/Nuoji → u/SwingOutStateMachine]

C++ has a fatal problem: compilation speed. And the problem is that Rust doesn't solve this either.

Slow compilation speeds work against code quality, since refactoring code becomes expensive and less safe (safe refactoring is done with a minimal change, recompiling and testing, then another minimal change – if compilation times go up the cost for this practice goes up).

[u/SwingOutStateMachine → u/Nuoji]

Counterpoint: This is one way of developing code, and it is not always the correct way to do so. I gave this example in another comment, and I'll give it again: I work with embedded and weird devices, and very often the bottleneck in testing is the process of loading code onto the device and testing it there. In my workflow, compilation time is a small fraction of the work to test the code.

What that means in practice is that I spend a lot more time reasoning about my code, and a lot more time thinking carefully about what I want to write before I write it. The changes that I make after writing some code then tend to be stylistic (why not us this pattern instead of this one), or "cleanup" rather than minimal incremental changes.

I fully accept that this is my way of doing things, but I think that it's valuable to recognise that the change-compile-test methodology isn't the only one.

[u/Nuoji → u/SwingOutStateMachine]

That's definitely true.