At this point, is anybody writing new C or C++? It seems like they are sunset languages even at the big corps.
As a solo programmer, I still prefer C and C++. In fact, as I've incorporated LLMs in to my workflow, I've been increasingly drawn toward C and its simplicity. A lot of the QoL features of C++ simply aren't needed when you're writing less code manually.
Other than a few examples given in the past, the Rust adoption among WinDev doesn't seem to be really taking off like in Azure.
Indeed C# is getting more low level coding features, and the unsafe memory model is being redone in .NET 11 for a reason.
Apparently outside WinUI efforts, that many don't care about, there isn't much going on, the Rust action is all on Azure side.
Rust for systems programming, C# for non-performing bound tasks (control panels, launchers, light gaming, GUI's on top of Windows CLI tools) and C++ for raw performance. And, still, I won't let any modern codec for A/V to be written in C/C++ for obvious reasons. And I am a diehard Unix+C user in the infamous N270 netbook. but dark times with automatic AI attacks are comming ahead. That's why I migrated from Mutt to Aerc, while keeping my Maildir and msmtp/isync.
At least I will be able to reencode potential harmful media for 420p/720@30FPS for the netbook in the NUC if FFMPEG (or FFMPEG based tools) were converted into Rust without hitting several vulns, because they will be everywhere:
- qemu/libvirt
- imagemagick/graphicsmagick, both the tools and libraries
- any libav* codec/parser
- libpng/libgif and similar
- zip/7z/tar/pax
- PS/PDF, of course. Especially PS, for obvious reasons.
- Some DOC/XLS formats pre DOCX are raw memory dumps and maybe they can be partially executed.
- Some other formats can act like a mini-VM bytecode too, such as RAR.
I even compiled Bubblewrap too so I can jail some of these, and yet I don't trust them 100%. Some recent exploits bypassed the chroot like nothing.
C# to me compares to Java and Kotlin (they have a large runtime or VM and implement GC).
Rust compares to C, C++, Zig or Odin (compile to native, memory is more self-managed).
Like, I agree that C++ will be around for a long while, but the writing is on the wall.
15 years of pre LLM or post LLM ?????
There's no reason to think that current game engines will have their fundamental APIs around scene management, serialization, entity composition, and so on, ported directly to Rust, because these things are typically designed around available language features. For example, an engine written in C++ might have its own version of `dynamic_cast` and RTTI, and that's going to be an extremely awkward design in any other language.
I think 15 years is too high, but I agree that it will be a while, because a triple-A game engine is a huge investment.
Rust's type system is making it's compile times bigger than C, C++ and Zig. This does keep it away from some code that's currently C or C++.
But Rust's type system an borrow checker are not something you want to go without in Rust, while in C++ many codebases prevent the use of some features to reduce compile time right?
“Traditional” C++ looks a lot more like Java, and often like C.
Much of the compile time of both Rust and C++ comes from monomorphization and linking, both of which do a lot of work to support the zero-cost high-level abstractions favored by both languages.
> Rust’s type system and borrow checker are not significant reasons for its compile times
But isn't "hard" monomorphization a property of more complex type systems (generics, type variables, etc.)?
From the job postings, many of them seem to be physics simulations of various kinds where (in my experience) memory is allocated on the heap without a second thought. Well, there are second thoughts, but those second thoughts are about performance.
This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.
There’s also work actively ongoing to make certain constructs even easier to express more ergonomically and letting user programs implement some of the magic that’s currently restricted to the standard library
If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
If you actually care about performance where you'd start is with measurements. What we see so much from C++ isn't measurements it is dogma. Things C++ forces on you must dogmatically be imagined as free without measuring them, things C++ does not have get treated as expensive, again without measuring so as to justify their absence.
For example, the unstable sort in C++ (std::sort) is typically implemented in a way which introduces Undefined Behaviour if your ordering isn't coherent either because you didn't realise that was mandatory or through some minor programming error. In contrast all of Rust's unstable sort implementations have been entirely safe even in the face of such mistakes.
And your dogma might tell you OK, but the C++ sort must be faster. That's why we're doing unsafe things, it must be faster. Except, nope, slower. Slower, but unsafe. Pointlessly worse. Only acceptable because of dogmatic belief.
90% of the code I write these days is Rust. It's a great tool, and the performance/safety balance, as well as general developer experience makes it well-suited to a wide variety of applications.
But in the past I've also built an ECS implementation. For that to optimize performance (and yes I did measure this) you want to do bulk memory allocations memory, pack bytes in order to minimize cache misses, and dispatch multiple threads to read and write concurrently over your memory pool. You can do all that in Rust, and people have, but it's a pain in the ass.
And for example, if I were working on a high-frequency trading application, where every millisecond of additional latency represents millions of dollars of lost revenue, I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
Rust is an amazing tool, but that doesn't mean it's the optimal tool for every job.
Obviously like Michael Burry it is always possible that I'm wrong and I can't see why. But I did give you a specific example where the dogma says well we have to choose this unsafe way to do it, but the reality is that's not only unsafe it's also slower. It is just worse.
I am glad to hear that you measured. I've been yelling at people for not measuring for much longer than Rust has existed - if people measure and choose C++ because the numbers were better I feel a lot better about that outcome.
As to being the right tool, I firmly believe we should use a lot more niche languages which do only one narrow thing very well. One common thing you'll see argued about the Memory Safe languages is that they need runtime bounds checks and such checks are a performance cost the unsafe languages do not incur. WUFFS illustrates that if we're willing to give up generality we can have a language which is entirely safe but doesn't do runtime bounds checks - because it proved mathematically at compile time that your code has no bounds misses so such checks are needless.
Arguably for HFT in particular the dirty secret is that if things go badly enough wrong you just say "Oops" and get a do-over because money isn't real.
With that being said, I did write a compiler to specifically help me match C++ memory layouts in Rust [0], so I might be an outlier case :-)
I understand your argument as "it's easier to botch an implementation in C++ than in Rust", which is true and that is actually an argument in favour of Rust.
I strongly believe it is harder to write a C++ implementation that is sound and does not rely on UB.
The point is, there are some domains (data-oriented programming) where Rust actively resists the kind of work you need to do to solve the problem in an optimal way, and it makes sense to use a language built around the type of memory management required.
There's no point in using Rust when 90% of your work is deactivating the benefits Rust provides and working around its default behavior.
Rust will replace C++. C will we kept as a "low level ASM" similar to what inline ASM was for C.
Still, I can perfectly predict Rust based Qemu and FFMPEG's being rewritten from Bellard et all replacing the former C base. Legacy users can just use legacy machines with Hyperbola (and I'm one of them), but Rust will be almost mandatory to be protected against automatic AI attacks. Kinda like blaster/sasser but much worse. Multiplatform virii written in Golang for instance.
Servers getting poisoned media targetting ImageMagick/GM and FFMPEG on purpose, and VM's too. Thus, rustifying Qemu/Libvirt and FFMPEG will almost be a mandatory task.
Again - no one takes issue with the ease argument. The only issue was claiming that c++ somehow let you go faster. Indeed, it’s likely not the case because rust has stronger aliasing protections that let it emit more efficient code, closer to Fortran - that’s why the old math libraries you’re probably using in c++ are written in Fortran and not c++ (rust didn’t exist and Fortran enforces no aliasing whereas c++ doesn’t).
No, Rust _has_ a stable ABI, it's the C ABI. It just isn't the default.
I can confirm that this has been sufficient for all of my memory layout needs, including interfacing with existing C/C++ code in memory.
Even disregarding tooling I'm actually happier writing C than (even) Odin because it's really just a natural end state of changes I'd made to how I write code over the past 7-8 years and what I expect from a language (to not do much, and to not get in the way).
It's hard to compete with the tangibles of writing/using C:
- Somehow it has shorter compile times than everything else still, particularly for release builds?
- Everything that matters (to me) has C bindings.
- All the tools just work and they work well (and a lot of them are made specifically for C anyway).
- The compilation model is actually better, more straight forward and easier to make fast than languages that try to "fix" it, unless you sit there fighting it and overcomplicate it with overwrought build systems. (`make` is better than I used to give it credit for, though).
I think Ada is the only language that could peel my attention away from C at the moment, which is ironic given my "Don't do much, get out of my way" stance. It turns out you can do more if you're sensibly designed, have the right escape hatches and actually provide real, useful features (basically every feature regarding arrays in Ada and their interplay with other features like index types, etc.). Ada is not as easy to port from Odin, though, and Ada would be a much bigger gamble than C in so many ways. We don't mind writing the code we use ourselves (we in fact prefer it), but in Ada a lot of that code would be decidedly alien to how Ada seems to work in many ways.
With that said, I do have an Ada port of a game I was working on that does illustrate a lot of upsides. It's a different possible end state.
P.S. I've tried Zig, I wrote Zig for several years before I started using Odin, it's what got me back to imperative, small, native languages. It's what started this journey back to C.
If you've sworn off actually getting any value from the programming language so much that you even went from Odin to C it feels like just writing raw assembler is a sensible choice at this point?
I haven't sworn off getting value from programming languages, I've just concluded that most languages are not useful and good enough to make me deal with the problems they have with tooling, complexity and so on over C.
Your suggestion to use assembly may be you trying to be hyperbolic, but I don't think it's nearly as hyperbolic and ridiculous as it'll sound to a lot of people. I personally think I get plenty of value out of the facilities C provides now, especially with later editions, but it may also be that it'd be holistically better to simply write assembly.
Because that's really what it comes down to: The big picture version of a lot of languages are that while the languages themselves may seem like an upgrade, their interaction with debuggers, etc., are not. A concrete example of this in Odin is that debuggers do not work particularly well with tagged unions (tagged unions have concrete integer values for tags in Odin, and the unions are generated anonymously and are not clear regarding which case is which), so whichever upside you have with language support for tagged unions, you'll still pay for it at debugging time. Meanwhile, in C with real enum types as you have in C23, your tag will be whichever enum value you have, i.e. readable and understandable, and your actual union cases will be exactly what you named them.
For just about every feature I like in Odin I have a similar story of where it falls apart with regards to tooling and other things. A "good language" doesn't mean that actually developing with it is any better than developing with an arguably less featureful and "worse" language.
I spent a considerable portion of my career writing C. But for the past few years I write only Rust in my free time (I do write little snippets in other languages, including Odin, but nothing serious)
Debugger support is like any other tooling problem, you need somebody who agrees with you about what the tools ought to do - to do the work. In C there have been decades for somebody to put together the rudimentary pieces needed to debug C and that's hardly a tall order
In the specific case you cited (tagged unions) you need a better pretty printer and you need Odin to emit the debugging info so that the debugger can understand these types and the pretty printer can display them to you. Without that you're staring at raw data and no surprise it doesn't feel like C would be less useful.
So yeah, it's not that you can't have a debugger that understands all of Odin perfectly, it's more like the reality we do have is one where basically none of them understand Odin perfectly, one has built-in (read-only) support for just slightly better Odin-specific views/functionality, two have read-only support (no interaction with built-in types because they use magic intrinsics behind the scenes and magic syntax) for Odin with custom scripts you have to load and everything else is just looking at C.
I've written Odin for 4+ years at this point, so it's not really as if this is a knee-jerk reaction to initial friction. I've spent the time and at this point I am very certain that I don't want to spend any more time with languages where tools are always bad or leaning towards bad, because I've realized that tools are really much more important to me than the languages themselves. I might even start using a language server again because C has one that's ridiculously fast in comparison to what you get with Odin, and it probably won't crash several times a day as soon as you get over some mild threshold like 25k lines, or a "whopping" 5k line file.
I don't much like Odin (Bill banned me from his Reddit because apparently I'm "just an arsehole") but in 2026 I couldn't live with C's attitude to strings. Odin's choice (using the fat pointer string slice type as the sole type for both owned strings and references into them) sucks but at least it has the fat pointer string slice type.
Why not Zig then, and C instead?
As a C/Zig outsider, I'd much rather read Zig.
Mind you, both of these languages are excellent compared to most other languages (there are a bunch of languages I've used that I'm not mentioning here because they're not even really worth comparing with), and there are certainly languages with worse tooling and overall worse outlooks for how to deal with issues. I don't want to give the impression that I dislike either Odin or Zig. They're just competing with C in this comparison, and by my estimation the holistic experience of developing in C is better than in either of them.
Ah and Rust's compiler backend dependency on LLVM and in the future GCC as well.
> Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub.
https://www.phoronix.com/news/Frame-X11-Server-Assembly
The eating everything part is only the usual hype cycle as folks update their CVs, in this fashion driven industry.
Except this time around AI makes language knowledge meaningless, we can vibe code anything into any language.
Naturally everyone around the globe that contributes to LLVM will gladly contribute the rewritten version as well.
Also, there's some C compiler in Rust, enough to build some crates.
I expect migrating my MUTT setup against isync/mbsync with some Golang written MUA targeting my maildir folder. I will lose some speed but I'm not at mail 24/7 in the netbook and Slashem doesn't demand a lot for gaming. Oh, and S9 Scheme and Klong for sure they work with very little, same with MupDF, sxiv for images and MPV. But, as I said, batch-mode communications will be mandatory on that device. Download, upload, disconnect. Every answer to discussion threads will be done offline.
AERC as a mail client it's written in Go and it's supports Maildir, so that's it.
Also, if someone created some SLRN fork rewritten in Go it would work in the exact same way. Slrnpull to fetch, some Go based reader pointing to the caché folder. Secure and not as slow as anyone would think.
Given how many vulns are discovered maybe even pledge/unveil under OpenBSD won't be enough. Call me crazy, but if all the OBSD people migrated to Redox OS keeping the MIT license it could be a crazy move and maybe a surreal end to the BSD Unix mythos, but it might be a much needed evolution, kinda like plan9/9front was against the old plain Unix philosphy. Evolve or die.
This kind of arguments is what gives raise to the Rust Evangelism Strike Force memes.
In some hypothetical LLM-free world where Rust is displacing C++, hiring managers will still consider C++ experience a strong signal. As is, see you at the bread lines, comrade.