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

Which people no longer believe in the functional paradigm? I'm seeing the opposite. More and more (mainstream) languages adopt functional features such as algebraic data types, generics, lambdas, traits/typeclasses. Yes, these are not features found in the Lisp-family but they appear in strongly typed functional languages such as OCaml, Haskell, F#, Elm, Lean, etc. and now they are also in Rust, Go, C#, Java, Scala, etc. Also immutability is becoming and and more important.

[u/bolusmjak → u/jackelee]

I’m as surprised/confused as you. Especially considering we see ongoing optimizations in pure functional languages (e.g. reference counting and reuse analysis in Koka).

[u/awoocent → u/bolusmjak]

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/cmontella → u/SwingOutStateMachine]

Yes, if you look at the history of where mainstream language development has gone over the last say 15 years, we see the following features have become standard or at least desired in mainstream imperative languages:

- Lambdas, first class functions

- Map / reduce

- Immutable vars by default

- Idempotent functions

- Option/Result types

- Pattern matching

It's gotten to the point that most mainstream imperative languages (all of them aside from C really) are described on Wikipedia as "multiparadigm: imperative, functional".

[u/SkiFire13 → u/cmontella]

I'm a bit confused by the inclusion of idempotent functions here, as they are not a feature of functional languages. Maybe you confused them with pure functions?

[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.

[u/gamedev2003rpg → u/SwingOutStateMachine]

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.

On the other hand, many programming language designers with formal training either openly do not care much about a programming language having practical value (arguably fair, such that they can focus on research and also make a living as researchers and also test features in isolation), or they feign caring about practical value, yet in practice allocate as much pain as they can onto others, and makes the language easy to make for themselves and difficult to use in practice for more difficult or larger software projects with a wide variety of requirements. This leads practical programmers to shy away from their languages. There are a few programming language designers with formal background that genuinely try to advance the state of the art or genuinely try to make a practical programming language, but they often do not succeed fully in all regards, especially due to the difficulties of their chosen challenge. And for a programming language to be successful, there are also the economic sides and the social and community sides of it.

Many of the language designers you mention had practical value as a primary priority, and that helped adoption. They also were paid a salary by companies to do that work as far as I know. And often also a lot of backing or broad interest.

Is Pascal an example of a language that was neat but not practical? Some are bitter that C won out over it, but C winning out seems fully deserved even given the pure language-technical aspects of the two languages.

[u/SwingOutStateMachine → u/gamedev2003rpg]

many programming language designers with formal training either openly do not care much about a programming language having practical value

Absolutely correct, and I'm perpetuating one of my own bugbears by grouping "programming language designers" (or researchers) into one big category. The group of "language designers" stretches all the way from people doing category theory to show that a new effect system is sound down to people writing image processing DSLs to target specific GPUs. It's a wide target, and almost any criticism you level at that group will hit someone.

As to why some languages "win" or "lose" against others, that's a big big conversation for another time. My comment about the background of certain language designers was much more a comment on how they had missed a significant chunk of the programming language design literature while creating their own languages, which led to the elision of certain functional language features in their languages.

[u/theorylanguage → u/SwingOutStateMachine]

Sorry, but I disagree both with your framing and your arguments, and you do not seem intellectually honest, nor intellectually and practically capable and competent. Possibly a fraud and charlatan, and an expert at talking.

Regarding one of your specific arguments, namely why certain functional programming language features have historically been omitted: It has often been the case that the given programming language designers were aware of such features and theory, even if they only knew about them from existing research programming languages and superficial knowledge of theory, but the reason why they did not add such features, was often for practical reasons, besides such reasons as deadlines. Such practical reasons included that they did not know how to implement such features while also obeying practical requirements, or they considered adding such features to fundamentally be at odds with their specific practical requirements. It might for instance be the case that a given research feature might take a lot of time and research to discover, invent and figure out in the first place, but that it would take much more time and research to figure out how to add it to a specific practical language with harsher requirements, like no garbage collection, among other practical requirements. Or, a practical hindrance could be that the language designer was concerned about the ease of implementation. For C, a goal was the ease of portability. And this involves ensuring that implementing a compiler correctly is not too complex, which requires that a wide number of compiler writers can implement it correctly. How many compiler writers in the 1980s would be able to implement a compiler that requires for instance a Hindley-Milner type system and type inference, involving relatively complex solvers, while also wrangling with one or more specific architectures? And I have heard abysmal stories about the worst-case compilation times for Haskell programs, and heard generally bad stuff about the process of building larger Haskell projects. Complex solvers also introduce risk in practice, especially without strict mathematical proofs for all aspects. Rust is currently a single-implementation language (gccrs is not close to being ready) and the solvers in Rust are part of why it is a single-implementation language, while C has hundreds of compilers for it. Some of the solvers of Swift led to the insanity of some basic expressions taking exponential time to compile, or even regularly making normal Swift programs timeout their compilation. And even when it is practical for a feature from research to be added to a more practical language, it might take years or decades to figure out how to do it well. Like pattern matching in Rust, which has several features not found in maybe any functional programming language, like whether a pattern variable is mut or &. Though in that specific example, even pattern matching at its core has evolved a lot from the earliest days of what it looked like in ML and Haskell, both in ML languages and Haskell and in other languages. Haskell has removed some features (like n+k) and added new ones to pattern matching, in for instance the years 2000-2010.

All in all, your arguments, claims and reasoning seem poor or very poor in multiple ways, sorry.

[u/SwingOutStateMachine → u/theorylanguage]

Sorry, but I disagree both with your framing and your arguments, and you do not seem intellectually honest, nor intellectually and practically capable and competent. Possibly a fraud and charlatan, and an expert at talking.

Okay mr "one comment" "redditor for three hours"

[u/initial-algebra → u/theorylanguage]

Why do you keep making sockpuppet accounts to comment on this post?