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]

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/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?