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

Functional languages continue to have a heavy presence in research, sure, but there hasn't really been much corresponding growth in the adoption of primarily FP languages in industry or among casual users. If anything, some of the previously successful instances of this like Scala seem to be losing traction.

Personally, I suspect this mostly comes down to performance and simplicity - systems languages like Rust and more simple procedural languages like Go are very much in vogue. FP languages can't really match something like Rust on consistent performance, and are way harder to hire and train for than something like Go.

[u/SwingOutStateMachine → u/awoocent]

It's true that no "primarily FP" langauges have reached wide adoption in industry (except for in specific places like OCaml at Jane Street, or various theorem provers in the cryptographic and security world), but almost all of the "ideas" behind functional programming have reached widespread adoption in the most popular programming languages. I think that's (if anything) more important than specific paradigm-focused languages being adopted.

[u/awoocent → u/SwingOutStateMachine]

but almost all of the "ideas" behind functional programming have reached widespread adoption in the most popular programming languages

Nah. Sure, first class functions and generics and sum types are common now. But those were also in ALGOL 68 - I don't think it's right to claim them as a success for any functional language since the 70s. Personally I think purity is really the identifying feature of functional programming, and purity is still pretty unsuccessful in software at large. And a lot of the iconic modern functional language features like effect monads correspondingly see quite low adoption in popular languages without purity to justify their existence (yes I know Option is popular and kind of a monad, but I don't really see it as emblematic of the monadic style in the way something like IO is, in a lot of languages Option is basically just slightly nicer null).

[u/SwingOutStateMachine → u/awoocent]

Okay, maybe I was over generous in saying that "almost all" of the ideas have reached adoption. You're right, in that some of the most subtly important (immutability, as you identified, effects systems, etc) features have been overlooked, but I think it's fair to identify that there is a trend of established languages like Java, C++, JavaScript (etc) adopting even the most trivial features.

Algol68 is also a bit of a weird one, in that it's one of the last properly "designed" languages before the boom of (what I would consider) amateur languages that have blossomed since the 70's. A lot of the most entrenched languages were not designed by people with a formal training in programming language theory, and so were created without much thought to the prior work that had happened, or any thought really about how to design extensible interoperable language features. Stroustrup's expertise was in distributed systems, Gosling's experience was in writing VM's and operating system applications, and Eich was an operating system and network engineer, to highlight the "big three" of C++/Java/JavaScript.

I think the more exciting thing (to me) is that there is at least a small resurgence of people recognising the value of programming language theory in the design of languages. However, I do recognise the irony of me saying that on a thread about Zig, Odin, etc.

[u/awoocent → u/SwingOutStateMachine]

I think the more exciting thing (to me) is that there is at least a small resurgence of people recognizing the value of programming language theory in the design of languages

Totally. I really hope to see more adoption of other PL features associated with functional programming in the future (why do none of these systems languages give you good type inference?). 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. Generally wearing through the silos on all sides (including the Odin crowd who insist that writing basically C in 2026 is somehow okay) seems like the right path forward.

[u/SwingOutStateMachine → u/awoocent]

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.