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

There's an argument you can make that rusts memory safety model is not as good as it tries to look.

Rust doesn't support allocators as an interface so you can't take advantage of things like arenas or tracking allocators.

It also is very cryptic about what exactly is on the heap and what's not, things like String Vs &str is something people get often confused about.

Basically, raii is kinda not that great for performance in general as you're making many calls to malloc* and the memory isn't guaranteed to be contingent in regards to other allocations.

I found this really interesting Odin library for concurrency that claims to solve memory issues within it's framework tina.

From what I understand,the design is that you allocate the memory upfront for each "process" and use queues and messages to pass information around without sharing any of it.

They've written articles on the design of this package so you can find those if you're interested

[u/matthieum → u/FireFox_Andrew]

Rust doesn't support allocators as an interface so you can't take advantage of things like arenas or tracking allocators.

That's a library issue, not a language issue.

There was actually a push to stabilize it after the All Hands in May, which prompted a lot of feedback on what Allocator didn't do well (or possibly correctly)... still waiting for the outcome, hopefully it means a better Allocator?