In theory Odin 2027, the 1.0 release of Bill's Odin language, is scheduled for, as the name suggests, early 2027. Zig does not have an announced 1.0 schedule, and who knows for the other two famous Handmade languages.
From the rash of "C++ successor" languages a few years ago, Carbon is still being worked on, Herb Sutter's "Cpp2" seems dead or at least in a coma, Hylo is probably also in a coma, it has several "Write this text" type blog posts, dated 2025 for example...
Jai and... C3? FilC?
Or something like SoftBound, from 2009,
https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf
It hasn't been for lack of choice.
[0] - https://learn.microsoft.com/en-us/cpp/c-runtime-library/debu...
Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use.
One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired.
† In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.
https://adspthepodcast.com/2026/08/21/Episode-300.html
Cpp2 was Herb's experiment and doesn't seem to be developed much further now,
https://github.com/hsutter/cppfront/discussions/1450
Google is still quite keen in having Carbon, for the purpose of migrating existing C++ codebases, for new code there is Rust, Go, Kotlin, Java, Swift and co.
"Carbon: graduating from the experiment - NDC Toronto 2026"
Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.
If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust!
It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art.
This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.
> But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative.
I see this on here a lot on this site, but Rust hasn't been that in over a decade. Rust's devotion to post 1.0 stability is massive and has involved some interesting design choices. I started writing run in 2015(?) and only hit one breaking change in the language. It was a niche bug in a macro that was fixed later in a later release.
Just watching hackernews you see lots of news about it, but these are additive and not breaking things. I was still writing lots of mio-style async code after async await was out. You don't have to adapt new style or libraries. I used to have a joke that you could tell a codebase's age based on the error handling libraries used, but even with that it was additive. Often multiple would exist in different parts of the same code base. "Oh wow, I've gone deep on this refactor.... I'm starting to see error_chain"
At that same job we hit a pretty nasty breaking change where mem::uninitialized() was deprecated and this turned out to cause a lot of critical async libraries to explode at runtime. But these sorts of things don't really happen anymore. The editions system is an excellent design and a big contributor to making the language and stdlib reliable.
Alas, that ship has sailed and Rust has many interesting features so I'm comfy with it taking over the role of C/C++ over the next decades.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Microsoft needs to choose for AOT Full Monty and leave the CLR behind.
Whereas Bethesda and Paradox (mainline strategy) games are examples of games that are intentionally moddable, with Cpp cores wrapping sanely defined content sandboxes.
Frankly I'd rather the C# style of modding didn't exist at all. It usually means the devs haven't thought about how mods should hook in at all, beyond "inject whatever you want and we'll break it on almost every update. Also, we don't have the resources to review mods so expect them to occasionally be/come malware. We take no responsibility even though we're literally the ones distributing the malware to you via our first party mod store."
Bethesda is not a very good counter-example, in my opinion, because they regularly** break mod support. I don't know enough about how these mods work to be sure, but given that the 32-bit to 64-bit transition was one such major breaking event, I am suspicious that they are not actually effectively sandboxed. I also don't play many Paradox games (and the one I did play a lot of, Cities Skylines, is a special case, and also a Unity/C# game), so I don't know how they do things.
The best example I know of for strong, sandboxed, first-party mod support would be Factorio and its Lua mods. However, these mods are constrained to doing only those things the game developers anticipate and want to allow, which means every mod for Factorio produces a very Factorio-flavored experience, though AFAIK there are some extension points in the API which are only really used by mods (or were, at least, before the Space Age expansion).
The biggest downside of C# (and Java) mods is indeed security, but the biggest upside is that a lot of games can add modding support without too much extra work. Such extra work is often not possible (they don't own the engine) or unlikely to happen (they don't have the time/budget), outside of special cases.
* = Whatever else you might think of Nexus Mods and its policies and drama, they generally take malware seriously
** = Roughly every 3-4 years, which means it's happened like 4 times with Skyrim, and one of those was so major that it completely split the mod ecosystem
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
While the idea was interesting for many of us, Microsoft really failed fumbled the delivery and the CLR is here to stay.
Also it would never going to fly as cross platform technology, given its design as an evolution of COM infrastructure.
Linus is a wise operator at this point. I often see him come in like a hammer to bash down squabbling, but then he allows the situation to evolve once things quiet down. I only saw the hammer so I'm not sure what the current state is now.
It looks like later, in December 2025, Rust was officially moved from experimental to official: https://lwn.net/Articles/1049831/
I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.
I bet you never heard of Microsoft. Fast, they don't move. But boy, are they slow at fixing bugs.