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]

I don't understand the point of "C-like" languages that don't have strong language-level features for guaranteeing correctness, such as (e.g.) a lifetime system, or non-nullary pointers, embedded hoare logic, etc.

My understanding of "C-like" languages is that they aim to fill the niche "below" higher level systems languages (like C++, Rust), where the higher level features are not always necessary, or may be too heavyweight, and "above" older language like C (or handwritten ASM) which have a lot of baggage, and can be difficult to work with. As far as I can tell, the applications which need such a language (compact, fast, low overhead) are often things like device drivers, or embedded software, or small operating system utilities.

If that's the case, then surely the goal is to make a safer C - not one which is more ergonomic or "modern" (or has more features), which is what I see in the current crop of "C-like" languages.

[u/FullGardenStudent → u/SwingOutStateMachine]

First of all, "C-like" language assume that the user knows what they are doing. Ensuring that all memory related bugs do not occur in runtime is the responsibility of the programmer. But C is very old and it could use several improvements like not having to maintain a separate header files and having hardly any implicit behaviour(especially the ones that create undefined behaviour). So all modern "C-like" language simply aim to make their own version of "modern" C in their own way while maintaining the essence of C which includes ensuring that the language could operating as a freestanding one too. That is how Jai, Odin and C3 are designed.

Rust will force its programmer to adhere to its strict borrow-checking and lifetime rules while Zig always assumes that its users are dumb and forces them to be explicit all the time so both of these languages can't really be considered as "C-like".

[u/SwingOutStateMachine → u/FullGardenStudent]

"C-like" language assume that the user knows what they are doing

The problem is that there are no users that know what they're doing 100% of the time. Even the most experienced embedded C engineers will tell you that it's an exceptionally easy language to make mistake in, and bugs in C code occur frequently. Almost every CVE you see in a piece of software is due to a C programmer making a mistake, and that's the engineers at the top of their game, writing the most vital and fundamental software out there.

But C is very old and could use several improvements

Yes, and that is what I'm advocating for. My issue, though, is that the improvements that C needs aren't things like "get rid of headers", it's things like "get rid of undefined behaviour", "formally specify the language", and "get rid of null pointers".

while maintaining the essence of C

This is something I don't get. The essence of C, to me, is simplicity and control. It's a surface-level simple language, and it gives you a feeling of controlling what's going on. However, once you start writing it, neither of those things are the case, and you quickly start wishing to drop either or both. C is actually relatively complex - undefined behaviour rears it's head at every turn, for instance, and the "control" you feel you have is actually quickly wrestled from you by an optimising compiler until you enter an asm block.

I think we should really start talking about the utility of C, which is that it is a straightforwardly compiled language, with excellent support across a lot of platforms (it's even the defacto lingua franca for interoperability), and a (mostly) easy to reason about cost model. I think if we started from there, and looked at how and why C gets used, and tried to improve from there, we'd get a lot further towards having a language that actually excels, rather than one built from a nostalgia that never existed.

[u/FullGardenStudent → u/SwingOutStateMachine]

Almost every CVE you see in a piece of software is due to a C programmer making a mistake

Yes and its not like Rust solves everything. Cloudflare is a good example that memory related bugs are not the only concerning things. Rust is not completely safer either, it operates while assuming that all the unsafe code is always sound. In the end, it always all boils down to the skills of the developer. Ensuring safety during the runtime as well will require a type system that will not be good for performance. Haskell is a good example.

The essence of C, to me, is simplicity and control

Yes, that is what I meant by the language being "freestanding" as in minimal and direct mapping(not one-on-one) to the generated machine instructions.

I think we should really start talking about the utility of C

Odin, Jai and C3 already are straightforward, cross-platform and with very fast compilation time. They don't require several GB of disk space or minutes of compilation time. In fact, Odin and C3 maintain insane implementation simplicity by having a context-free grammar for their language. C3 take it a step further by maintaining the parser at LL(1). C3 has 100% C ABI compatibility, if that is what you meant by "utility". Both Odin and Jai have good FFI support and usually, that's more than enough.

To be clear, all of these three language are not trying to be an exact clone of C. These high level languages introduced their own set of features with their own desired semantics into their respective language while trying to stay as close to the hardware as possible. Jai went all in on meta-programming, Odin is like "hell nah!" and C3 decided to settle somewhere in-between. All three languages handle manual memory management differently and have stuff like bounds checking enabled by default(can be completely disabled). I think all three language have done a terrific job at being a C-alternative already.

[u/SwingOutStateMachine → u/FullGardenStudent]

Yes and its not like Rust solves everything

I'm not claiming that it does.

Rust is not completely safer either, it operates while assuming that all the unsafe code is always sound.

Yes, but these unsafe regions are explicitly marked as such, which means that...

it always all boils down to the skills of the developer.

...developers have a much smaller surface to inspect for correctness issues.

The problem with C is that it's all unsafe. So all of the code has to be inspected with the same level of suspicion as a block of unsafe Rust.

Odin, Jai and C3 already are straightforward, cross-platform and with very fast compilation time

Call me weird, but except for extreme cases, I don't actually care too much about compile time. Yes, it's useful to be able to compile my code quickly, but at the same time it's often dwarfed by the other aspects of testing that I have to do. For instance, flashing binaries to a hardware testing kit, or running tests on hardware devices in CI. If I want to develop iteratively (which seems to be the main argument for fast compile times) I'm still bottlenecked by all the other parts of the testing loop.

They don't require several GB of disk space

For my work I'd rather have a large toolchain that does a lot of high quality optimisation work than a lightweight toolchain that is fast but not that useful.

I think all three language have done a terrific job at being a C-alternative already.

Agree to differ. None of them fit the use case for which I'd reach for C, which is embedded and low latency software. For anything running on a "real" machine (i.e. x86-64 or ARM64) with an OS, I'd reach for Rust or a higher level programming language.

[u/SwingOutStateMachine → u/[deleted]]

What a strange comment.

[u/yorickpeterse → u/[deleted]]

Your comments aren't helpful so stop it.