Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?
Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, and the pointer size type are all the same type, which is not the case for a couple of architectures; it's also the case that things like segmented pointers don't really work in Rust (of course, they barely work in C, but barely is more than nothing).
Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).
There's a ton of standardization work that really should be done before these are safe for library APIs. Mostly fine to just write an application that uses one of these crates though.
Rust worded in its initial guarantee that usize was sufficient to roundtrip a pointer (making it effectively uptr), and there remains concern among several of the maintainers about breaking that guarantee, despite the fact that people on the only target that would be affected basically saying they'd rather see that guarantee broken. Sort of the more fundamental problem is that many crates are perfectly happy opting out of compiling for weirder platform--I've designed some stuff that relies on 64-bit system properties, and I'd rather like to have the ability to say "no compile for you on platform where usize-is-not-u64" and get impl From<usize> for u64 and impl From<u64> for usize. If you've got something like that, it also provides a neat way to say "I don't want to opt out of [or into] compiling for usize≠uptr" and keeping backwards compatibility.
If you want to see some long, gory debates on the topic, https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... is a good starting point.
The proper approach to resolving this in an elegant way is to make the guarantee target-dependent. Require all depended-upon crates to acknowledge that usize might differ from uptr in order to unlock building for "exotic" architectures, much like how no-std works today. That way "nearly every platform" can still rely on the guarantee with no rise in complexity.
Yet Rust is not Go and this solution is probably not the right one for Rust. As laid out in a link on a sibling comment, one possibility is to do away with pointer <=> integer conversions entirely, and use methods on pointers to access and mutate their addresses (which may be the only thing they represent on some platforms, but is just a part of their representation on others). The broader issue is really about evolving the language and ecosystem away from the mentality that "pointers are just integers with fancy sigil names".
Pointers should at no point be converted into numbers and back as that trips up many assumptions (special runtimes, static/dynamic analysis tools, compiler optimizations).
Additionally, I would make it a priority that writing FFIs should be as easy as possible, and requires as little human deliberation as possible. Even if Rust is safe, its safety can only be assumed as long as the underlying external code upholds the invariants.
Which is a huge risk factor for Rust, especially in today's context of the Linux kernel. If I have an object created/handled by external native code, how do I make sure that it respects Rust's lifetime/aliasing rules?
What's the exact list of rules my C code must conform to?
Are there any static analysis/fuzzing tools that can verify that my code is indeed compliant?
So as to not only hate on Rust, I want to remark, that baking in the idea that pointers can be used for arithmetic isn't a good one as well.
Can you expand on this point? Like are you worried about whether the external code is going to free the memory out from under you? That is part of a guarantee, the compiler cannot guarantee what happens at runtime no matter what the author of a language wants, the CPU will do what it's told, it couldn't care about Rusts guarantees even if you built your code entirely with rust.
When you are interacting with the real world and real things you need to work with different assumptions, if you don't trust that the data will remain unmodified then copy it.
No matter how many abstractions you put on top of it there is still lighting in a rock messing with 1s and 0s.
Assuming I'm reading these blog posts [0, 1] correctly, it seems that the size_of::<usize>() == size_of::<*mut u8>() assumption is changeable across editions.
Or at the very least, if that change (or a similarly workable one) isn't possible, both blog posts do a pretty good job of pointedly not saying so.
[0]: https://faultlore.com/blah/fix-rust-pointers/#redefining-usi...
[1]: https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_...
Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer <=> integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance.
I think the answer to "can this be solved with editions" is more "kinda" rather than "no"; you can make hard breaks with a new edition, but since the old editions must still be supported and interoperable, the best you can do with those is issue warnings. Those warnings can then be upgraded to errors on a per-project basis with compiler flags and/or Cargo.toml options.
Provenance-related work seems to be progressing at a decent pace, with some provenance-related APIs stabilized in Rust 1.84 [0, 1].
[0]: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0/
[1]: https://doc.rust-lang.org/std/ptr/index.html#provenance
One of those goals is that code which was written for an older edition will continue to work. You should never be forced to upgrade editions, especially if you have a large codebase which would require significant modifications.
The other goal is that editions are interoperable, i.e. that code written for one edition can rely on code written for a different edition. Editions are set on a per-crate basis, this seems to be the case for both rustc [1] and of course cargo.
As I see it, what you're saying would mean that code written for this new edition initially couldn't use most of the crates on crates.io as dependencies. This would then create pressure on those crates' authors to update their edition. And all of this would be kind of pointless fragmentation and angst, since most of those crates wouldn't be doing funny operations on pointers anyway. It might also have the knock-on effect of making new editions much more conservative, since nobody would want to go through that headache again, thus undermining another goal of editions.
[1]: https://rustc-dev-guide.rust-lang.org/guides/editions.html
The reverse is probably more true, though. Rust has native SIMD support for example, while in standard C there is no way to express that.
'C is not a low-level language' is a great blog post about the topic.
std::simd is nightly only.
> while in standard C there is no way to express that.
In ISO Standard C(++) there's no SIMD.
But in practice C vector extensions are available in Clang and GCC which are very similar to Rust std::simd (can use normal arithmetic operations).
Unless you're talking about CPU specific intrinsics, which are available to in both languages (core::arch intrinsics vs. xmmintrin.h) in all big compilers.
There was one accelerator architecture we were working that discussed making the entire datapath be 32-bit (taking less space) and having a 32-bit index type with a 64-bit pointer size, but this was eventually rejected as too hard to get working.
In the end, I’m not sure that’s better, or maybe we should have had extra large pointers again (in that way back 32bit was so large we stuffed other stuff in there) like CHERI proposes (though I think it still has secret sidecar of data about the pointers).
Would love to Apple get closer to Cheri. They could make a big change as they are vertically integrated, though I think their Apple Silicon for Mac moment would have been the time.
I wonder what big pointers does to performance.
Not really, at least not anymore: https://doc.rust-lang.org/std/ptr/index.html#provenance
This is also how Rust will work on CHERI. You can run your pointer-fiddling code in Miri today to check that you're following the rules.
Double-linked lists are also pain to implement, and they're are heavily used in kernel.
You mean in safe rust? You can definitely do self-referential structs with unsafe and Pin to make a safe API. Heck every future generated by the compiler relies on this.
I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.
Java, really? I don’t think Java has been essential for a long time.
Is Perl still critical?
https://linuxfromscratch.org/lfs/view/development/chapter07/...
Edit:
On my (Arch) system removing perl requires removing: auto{conf,make}, git, llvm, glibmm, among others.
I suspect what we are going to see isn't so much Rust making it through that door, but LLVM. Rust and friends will come along for the ride.
As much as I like Java, Java is also not critical for OS utilities. Bash shouldn't be, per se, but a lot of scripts are actually Bash scripts, not POSIX shell scripts and there usually isn't much appetite for rewriting them.
I don't agree with "any modern system" but some modern systems certainly don't come with perl.
I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.
...to the extent I could see it pushing Rust out of the kernel in the long run. Rust feels like a sledgehammer to me where the kernel is concerned.
It's problem right now is that it's not stable enough. Language changes still happen, so it's the wrong time to try.
You do get some creature comforts like slices (fat pointers) and defer (goto replacement). But you also get forced to write a lot of explicit conversions (I personally think this is a good thing).
The C interop is good but the compiler is doing a lot of work under the hood for you to make it happen. And if you export Zig code to C... well you're restricted by the ABI so you end up writing C-in-Zig which you may as well be writing C.
It might be an easier fit than Rust in terms of ergonomics for C developers, no doubt there.
But I think long-term things like the borrow checker could still prove useful for kernel code. Currently you have to specify invariants like that in a separate language from C, if at all, and it's difficult to verify. Bringing that into a language whose compiler can check it for you is very powerful. I wouldn't discount it.
Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does.
I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.
And it seems unlikely they’d go through all the effort of porting safer Rust code into less safe Zig code just for ergonomics.
Not like Rust does, no, but that's the point. It brings both non-nullable pointers and bounded pointers (slices). They solve a lot of problem by themselves. Tracking allocations is still a manual process, but with `defer` semantics there are many fewer foot guns.
> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.
The jump from 2 to 3 is smaller than the jump from 1 to 2, but I generally agree.
That was where my argument was supposed to go. Especially a third language whose benefits over C are close enough to Rust's benefits over C.
I can picture an alternate universe where we'd have C and Zig in the kernel, then it would be really hard to argue for Rust inclusion.
(However, to be fair, the Linux kernel has more than C and Rust, depending on how you count, there are quite a few more languages used in various roles.)
Rust is different because it both:
- significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities.
- And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld.
That doesn't mean Zig is a bad language for a particular project, just that it's not worth adding to an already massive project like the Linux kernel. (Especially a project that already have two languages, C and now Rust).
So aside from being like 1-5% unsafe code vs 100% unsafe for C, it’s also more difficult to misuse existing abstractions than it was in the kernel (not to mention that in addition to memory safety you also get all sorts of thread safety protections).
In essence it’s about an order of magnitude fewer defects of the kind that are particularly exploitable (based on research in other projects like Android)
So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years).
In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action.
As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident. Unsafe isn't a magic bullet, but it's a decent caliber round.
It reminds me of this fun question:
What’s the difference between a million dollars and a billion dollars? A billion dollars.
A million dollars is a lot of money to most people, but it’s effectively nothing compared to a billion dollars.
[1]: this the order of magnitude presented in the recent Android blog post: https://security.googleblog.com/2025/11/rust-in-android-move...
> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
It's "embedded programming" where you often start to run into weird platforms (or sub-platforms) that only have a c compiler, or the rust compiler that does exist is somewhat borderline. We are sometimes talking about devices which don't even have a gcc port (or the port is based on a very old version of gcc). Which is a shame, because IMO, rust actually excels as an embedded programming language.
Linux is a bit marginal, as it crosses the boundary and is often used as a kernel for embedded devices (especially ones that need to do networking). The 68k people have been hit quite hard by this, linux on 68k is still a semi-common usecase, and while there is a prototype rust back end, it's still not production ready.
I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.
Otherwise is yak shaving instead of working on the actual game code.
Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it.
Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.
Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain.
How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worthwhile to create, locate, awaken and then fight this dragon? C# with incremental GC seems to be more than sufficient for a vast majority of titles today.
Devil May Cry for the Playstation 5 was shipped with it.
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.
Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist.
> [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure.
Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside.
In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat.
But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class.
It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/
That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.
Most of the examples of "this is what makes Rust compilation slow" are code generation related; for example, a Rust proc_macro making compilation slow would be equivalent to C building a code generator (for schemas? IDLs?), running it, then compiling the output along with its user.
But of course that doesn't negate this cost, but building can always be done on another machine as a way to circumvent the problem.
It's only when you get very large projects that compilation time becomes a problem.
If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]?
if only due to the Lindy Effect
Even then, there are still some systems that will support C but won't support Rust any time soon. Systems with old compilers/compiler forks, systems with unusual data types which violate Rust's assumptions (like 8 bit bytes IIRC)
`clang-cl` does this with `cl.exe` on Windows.
Let alone the fact that conceptually people with locked down environments are precisely those would really want the extra safety offered by Rust.
I know that real life is messy but if we don't keep pressing, nothing improves.
If you're developing something individually, then sure, you have a lot of control. When you're developing as part of an organization or a company, you typically don't. And if there's non-COTS hardware involved, you are even more likely not to have control.
If someone writes a popular Rust library, it's only going to be useful to Rust projects.
With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*
Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
This is still the worst possible argument for C. If C persists in places no one uses, then who cares?
C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/
"Always has been" is pushing it. Half of C's history is written with outdated, proprietary compilers that died alongside their architecture. It's easy to take modern tech like LLVM for granted.
Yes, you can use it everywhere. Is that what you consider a success?
Languages like Rust a probably more successful in terms of age vs. adoption speed. There's just a good number of platforms which aren't even supported, and where you have no other choice than C. Rust can't target most platforms, and it compiles on even less. Unless Linux want's to drop support for a good number of platforms, Rust adoption can only go so far.
Wait, wait, you can use C everywhere, but if absolute lines of code is the metric, people seem to move away from C as quickly as possible (read: don't use C) to higher level languages that clearly aren't as portable (Ruby, Python, Java, C#, C++, etc.)?
> Rust can't target most platforms, and it compiles on even less. Unless Linux want's to drop support for a good number of platforms, Rust adoption can only go so far.
Re: embedded, this is just terribly short sighted. Right now, yes, C obviously has the broadest possible support. But non-experimental Linux support starts today. GCC is still working on Rust support and rust_codegen_gcc is making in roads. And one can still build new LLVM targets. I'd be interested to hear what non-legacy platforms actually aren't supported right now.
But the real issue is that C has no adoption curve. It only has ground to lose. Meanwhile Rust is, relatively, a delight to use, and offers important benefits. As I said elsewhere: "Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?" The future looks bright for Rust, if you believe as I do, we are beginning to demand much more from our embedded parts.
Now, will Rust ever dominate embedded? Will it be used absolutely everywhere? Perhaps not. Does that matter? Not AFAIAC. Winning by my lights is -- using this nice thing rather than this not so nice thing. It's doing interesting things where one couldn't previously. It's a few more delighted developers.
I'd much rather people were delighted/excited about a tech/a language/a business/a vibrant community, than, whatever it is, simply persisted. Because "simply persisted", like your comment above, is only a measure of where we are right now.
Another way to think of this is -- Perl is also everywhere. Shipped with every Linux distro and MacOS, probably to be found somewhere deep inside Windows too. Now, is Perl, right now, a healthy community or does it simply persist? Is its persistence a source of happiness or dread?
I never said Rust was the universal language, that is pleasing to all people. I was very careful to frame Rust's success in existential, not absolute or universal, terms:
>> Winning by my lights is -- using this nice thing rather than this not so nice thing. It's doing interesting things where one couldn't previously. It's a few more delighted developers.
I am not saying these technologies (C and Perl) should go away. I am saying -- I am very pleased there is no longer a monoculture. For me, winning is having alternatives to C in embedded and kernel development, and Perl for scripting, especially as these communities, right now, seem less vibrant, and less adaptable to change.
> ... yes?
Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.
I'm not sure why you think this is a problem that Rust has? Perhaps you mean something different but the Rust project compiles available code on crate.io upon the release of a new version.[0] C compilers may imagine their new compiler code doesn't break old software, but Rust takes that extra step, so we know it won't.
Now, the Rust kernel is currently using beta and nightly features which are on track for inclusion in the stable Rust compiler. So, yes, right now compilation is tied to a specific kernel version, and may need to be updated if a feature changes. However, any C compiler used to compile the Linux kernel uses non-standard GCC extensions only recently adopted by clang. Imagine if the C standards committee chose to change the syntax/sematics of a non-standard extension. Do you not imagine the non-standard extension would also be similarly deprecated?
The issue seems to be Rust is telling you what is non-standard, and you're yelling "Look it's non-standard!". But consider that the kernel in practice is using lots of non-standard features, and should the C standard simply adopt this non-standard behavior that means likely having to changes lots of code.
That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary architectures that nobody wants to have to actively maintain as part of the LLVM project. Right now, you usually need to use a fork of the whole LLVM project when using experimental backends.
This is exactly what I'm saying. Do you think HW drives SW or the other way around? When Rust is in the Linux kernel, my guess is it will be very hard to find new HW worth using, which doesn't have some Rust support.
You're putting words in my mouth there - that's not my point.
My point is that if they're not running linux, and the ones that are aren't running a modern kernel, then we shouldn't hold back development of modern platforms for ones that refuse to keep up.
For these cases you could always use Zig instead of C
Already setting the proper defaults on a Makefile would get many people half way there, without changing to language yet to be 1.0, and no use-after-free story.
And thats why Zig don’t offer much. Devs will just ignore it.
I know, a linked list is not exactly super complex and rust makes that a bit tough. But the realisation one must have is this: building a linked list will break some key assumptions about memory safety, so trying to force that into rust is just not gonna make it.
Problem is I guess that for several of us, we have forgotten about memory safety and it's a bit painful to have that remembered to us by a compiler :-)
This makes me wonder: what performance cost Rust code pay due to inability represent cyclic structures efficiently? It seems people tend to design their data in way to please Rust and not in way that would be otherwise more performance efficient.
> what performance cost Rust code pay due to inability represent cyclic structures efficiently?
You can still write the code you'd write in C with unsafe. There's no inherent loss left on the table.
Furthermore, a lot of C folks reach for intrusive lists because it's easy in C, but that doesn't mean that it's always the most performant. See https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... as an example of this phenomenon.
Lots of things C chose to use intrusive pointers and custom data structures for, you would program very differently in a different language.
I'm an old C neckbeard and I find Rust a great experience. Some of the arguments against it sound like people are complaining about how hard it is to run pushing a bicycle.
https://doc.rust-lang.org/src/alloc/collections/linked_list....
If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way.
That is how all standard library collections in Rust works. They’ve just gone to the length of formally verifying parts of the code to ensure performance and safety.
Rust is great, but there are some things that are safe (and you could prove them safe in the abstract), but that you can't easily express in Rust's type system.
More specifically, there are some some things and usage pattern of these things that are safe when taken together. But the library can't force the safe usage pattern on the client, with the tools that Rust provides.
Take a look at the unsafe functions for the standard library Vec type to see examples of this:
https://doc.rust-lang.org/std/vec/struct.Vec.html#method.fro...
Yes, that's what you do in practice. But it's no different--in principle--from the approach C programmers have to use.
Yeah and that's what not going to work for high performance data structures because you need to embed hooks into the objects - not just put objects into a bigger collection object. Once you think in terms of a collection that contains things you have already lost that specific battle.
Another thing that doesn't work very well in Rust (from my understanding, I tried it very briefly) is using multiple memory allocators which is also needed in high performance code. Zig takes care to make it easy and explicit.
It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...
And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be able to be chained in even if there are 0 bytes of free RAM ("Error: cannot free memory because memory is full" is probably not a thing you'd ever want to see)).
That's a great point! A language almost like C plus a smart enough compiler could do the unboxing, but this technique doesn't work for multiple structures.
> And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be able to be chained in even if there are 0 bytes of free RAM ("Error: cannot free memory because memory is full" is probably not a thing you'd ever want to see)).
I think you are right in practice, though in principle you could pre-allocate the necessary memory when you create the items? When you have the intrusive links, you pay for their allocation already anyway, too. In terms of total storage space, you wouldn't pay for more.
(And you don't have to formally alloc them via a call to kmalloc or so. In the sense that you don't need to find a space for them: you just need to make sure that the system keeps a big enough buffer of contiguous-enough space somewhere. Similar to how many filesystems allow you to reserve space for root, but that doesn't mean any particular block is reserved for root up-front.)
But as I thought, that's about in-principle memory usage. A language like C makes the alternative of intrusive data structures much simpler.
That is why kernel mostly (always?) uses intrusive linked lists. They have no such problem.
Same story for games where it can be in the list of all objects and in the list of objects that might be attacked. Once it's killed you can remove it from all lists without searching for it in every single one.
Is there known compilers that can do that?
The above is about the optimiser figuring out whether to box or unbox by itself.
If you are willing to give the compiler a hand: Rust can do it just fine and it's the default when you define data structures. If you need boxing, you need to explicitly ask for it, eg via https://doc.rust-lang.org/std/boxed/struct.Box.html
Like a linked list that forces you to add a next pointer to the record you want to store in it.
Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?
I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to make the choice, you are less likely to make yourself change (and more likely to make the junior people change, when there's a trade-off). Power corrupts, even on that small scale.
There's also a good argument for being stubborn and jaded: You have 30 years perfecting the skills, tools, efficiencies, etc. of C++. For the new project, even if C++ isn't as good a fit as Rust, are you going to be more efficient using Rust? How about in a year? Two years? ... It might not be worth learning Rust at all; ROI might be higher continuing to invest in additional elite C++ skills. Certainly that has more appeal to someone who knows C++ intimately - continue to refine this beautiful machine, or bang your head against the wall?
For someone without that investment, Rust might have higher ROI; that's fine, let them learn it. We still need C++ developers. Morbid but true, to a degree: 'Progress happens one funeral at a time.'
I believe the opposite. There's some kind of weird mentality in beginner/wannabe programmers (and HR, but that's unrelated) that when you pick language X then you're an X programmer for life.
Experienced people know that if you need a new language or library, you pick up a new language or library. Once you've learned a few, most of them aren't going to be very different and programming is programming. Of course it will look like work and maybe "experienced" people will be more work averse and less enthusiastic than "inexperienced" (meaning younger) people.
The "You can write Java in any language" mentality afflicts some languages worse than others, but if your programming is exclusively in a single language you will be tainted by that regardless of the language. C++ is perhaps worst for this because its proponents, and indeed its standards committee have their own terminology for everything. So there aren't "methods" but instead "non-static member functions" for example. This has the "Call a rabbit a smeerp" problem, where you can't tell whether you actually don't know a feature or if you just know the exact same feature by a different name.
I guess what I'm saying is that writing any language in an idiomatic way takes a bit more than just "programming is programming" plus a word-for-word translation guide, and some people might be weary of learning new idioms.
That heavily depends, if you tap into a green field project, yes. Or free reign over a complete rewrite of existing projects. But these things are more the exception than the regular case.
Even on green field project, ecosystem and available talents per framework will be a consideration most of the time.
There are also other things like being parent and wanting to take care of them that can come into consideration later in life. So more like more responsibilities constraints perspectives and choices than power corrupts in purely egoistic fashion.
Not most, but the pool of software devs has been doubling every five years, and Rust matches C# on "Learning to Code" voters at Stack Overflow's last survey, which is crazy considering how many people learn C# just to use Unity. I think you underestimate how many developers are Rust blank slates.
Anecdotically, I've recently come across comments from people who've taught themselves Rust but not C or C++.
Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.
It is easy to forget that the state-of-the-art implementations of a lot of systems software is not open source. They don’t struggle to attract contributors because of language choices, being on the bleeding edge of computer science is selling point enough.
I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).
I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.
Multithreading had not been planned or architected for, it took 30 min, included the compiler informing me I couldn't share a hashmap with those threads unsynchronised, and informing me on how to fix it.
These days even mobile phones have multicore CPUs, so it's getting hard to find excuses for single-threaded programs.
Zig would have been a nice proposition in the 20th century, alongside languages like Modula-2 and Object Pascal.
> ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free
which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".
It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?
I prefer not having to debug... I think most people would agree with that.
Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.
1. Memory safety - these can be some of the worst bugs to debug in C because they often break sane invariants that you use for debugging. Often they break the debugger entirely! A classic example is forgetting to return a value from a non-void function. That can trash your stack and end up causing all sorts of impossible behaviours in totally different parts of the code. Not fun to debug!
2. Stronger type system - you get an "if it compiles it works" kind of experience (as in Haskell). Obviously that isn't always the case, but I can sometimes write several hundred lines of Rust and once it's compiling it works first time. I've had to suppress my natural "oh I must have forgotten to save everything or maybe incremental builds are broken or something" instinct when this happens.
Net result is that I spend at least 10x less time in a debugger with Rust than I do with C.
There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon.
POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,...
Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded.
Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence.
Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.
Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing.
C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too.
C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there.
The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language.
Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like.
Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.
I wouldn’t say it’s inevitable that everything will be rewritten in Rust, at the very least this will this decades. C has been with us for more than half a century and is the foundation of pretty much everything, it will take a long time to migrate all that.
More likely is that they will live next to each other for a very, very long time.
I have never run into such a crate in the wild, I don't think.
By default, all it means is that unwinding the stack doesn't happen, so Drop implementations don't get called. Which _can_ result in bugs, but they're a fairly familiar kind: it's the same kind of fault if a process is aborted (crashes?), and it doesn't get a chance to finalise external resources.
EDIT: to clarify, the feature isn't really something crates have to opt in to support
I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.
C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.
People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.
FWIW I work in firmware with the heap turned off. I’ve worked on projects in both C and Rust, and agree Rust still adds useful checks (at the cost of compile times and binary sizes). It seems worth the trade off for most projects.
This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.
Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.
Rust has no_std to handle not having an allocator.
Tons of things end up being marked “unsafe” in systems/embedded Rust. The idea is you sandbox the unsafeness. Libraries like zero copy are a good example of “containing” unsafe memory accesses in a way that still gets you as much memory safety as possible given the realities of embedded.
Tl;dr you don’t get as much safety as higher level code but you still get more than C. Or maybe put a different way you are forced to think about the points that are inherently unsafe and call them out explicitly (which is great when you think about how to test the thing)
This means:
- All lifetimes are either 'stack' or 'forever'
- Thread safety in the main loop is ensured by disabling interrupts in the critical section - Rust doesn't understand this paradigm (it can be taught to, I'm sure)
- Thread safety in ISRs should also be taught to Rust
- Peripherals read and write to memory via DMA, unbekownst to the CPU
etc.
So all in all, I don't see Rust being that much more beneficial (except for stuff like array bounds checking).
I'm sure you can describe all these behaviors to Rust so that it can check your program, but threading issues are limited, and there's no allocation, and no standard lib (or much else from cargo).
Rust may be a marginally better language than C due to some convenience features, but I feel like there's too much extra work very little benefit.
https://github.com/rust-embedded/cortex-m/blob/master/cortex...
You can look at asynch and things like https://github.com/rtic-rs/rtic and https://github.com/embassy-rs/embassy for common embedded patterns.
You handle DMA the same way as on any other system - e.x. you mark the memory as system/uncached (and pin it if you have virtual memory on), you use memory barriers when you are told data has arrived to get the memory controller up to speed with what happened behind its back, and so on. You’re still writing the same code that controls the hardware in the same way, nothing about that is especially different in C vs Rust.
I think there is very much a learning curve, and that friction is real - hiring people and teaching them Rust is harder than just hiring C devs. People on HN tend to take this almost like a religious question - “how could you dare to write memory unsafe code in 2025? You’re evil!” But pragmatically this is a real concern.
> I'm curious why your perspective on Rust as a HW engineer.
C, C++ and Rust requires you to know at least the basics of the C memory model. Register variables, heap, stack, stack frame, frame invalidation, allocators and allocation, heap pointer invalidation, etc. There are obviously more complicated stuff (which I think you already know, seeing that you're an embedded developer), but this much is necessary to avoid common memory errors like memory leaks (not a safety error), use-after-free, double-free, data-race, etc. This is needed for even non-system programs and applications, due to lack of runtime memory management (GC or RC). You can get by, by following certain rules of thumb in C and C++. But to be able to write flawless code, you have to know those hardware concepts. This is where knowledge of process and memory architecture comes in handy. You start with the fundamental rule before programming, instead of the other way around that people normally take. Even in Rust, the complicated borrow checker rules start to make sense once you realize how they help you overcome the mistakes you can make with the hardware.
> Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists.
> This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.
I do have an answer, but I don't think it can be explained in a better way than how @QuiEgo did it: You can 'sandbox' those unsafe parts within Rust unsafe blocks. As I have explained elsewhere, these sandboxed parts are surprisingly small even in kernel or embedded code (please see the Rust standard library for examples). As long as you enforce the basic correctness conditions (the invariants) inside the unsafe blocks, the rest of the code is guaranteed to be safe. And even if you do make a mistake there (i.e memory safety), they are easier to find because there's very little code there to check. Rust does bring something new to the table for the hardware.
NOTE: I believe that those parts in the kernel are still in C. Rust is just a thin wrapper over it for writing drivers. That's a reasonable way forward.
> Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.
That isn't true. @QuiEgo already mentioned no_std. It's meant for this purpose. Here is the reference: https://docs.rust-embedded.org/book/intro/no-std.html#bare-m...
Apple has invested in Swift, another high level language with safety guarantees, which happens to have been created under Chris Lattner, otherwise known for creating LLVM. Swift's huge advantage over Rust, for application and system programming is that it supports an ABI [1] which Rust, famously, does not (other than falling back to a C ABI, which degrades its promises).
[1] for more on that topic, I recommend this excellent article: https://faultlore.com/blah/swift-abi/ Side note, the author of that article wrote Rust's std::collections API.
[0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.
> Embedded Swift support is available in the Swift development snapshots.
And considering Apple made Embedded Swift, even Apple does not believe that regular Swift is suitable. Meaning that you're undeniably completely wrong.
[0]:
https://github.com/swiftlang/swift-evolution/blob/main/visio...
You continue being undeniably, completely wrong.
For Apple it suffices that it is fit for purpose for Apple itself, it is experimental for the rest of the world.
I love to be rightly wrong.
https://www.swift.org/get-started/embedded/
Rust's approach is overkill, I think. A lot of reference counting and stuff is just fine in a kernel.
The big sticking point for me is that for desktop and server style computing, the hardware capabilities have increased so much that a good GC would for most users be acceptable at the kernel level. The other side to that coin is that then OS’s would need to be made on different kernels for large embedded/tablet/low-power/smart phone use cases. I think tech development has benefitted from Linux being used at so many levels.
A push to develop a new breed of OS, with a microkernel and using some sort of ‘safe’ language should be on the table for developers. But outside of proprietary military/finance/industrial (and a lot of the work in these fields are just using Linux) areas there doesn’t seem to be any movement toward movement toward a less monolithic OS situation.
There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re-creating it with the "new thing". And the "old thing" has some advantages the "new thing" doesn't have. So some very specific applications will keep using the "old thing". Other applications will use the "new thing" as it is convenient.
To answer your second question, nothing is inevitable, except death, taxes, and the obsolescence of machines. Rust is the new kid on the block now, but in 20 years, everybody will be rewriting all the Rust software in something else (if we even have source code in the future; anyone you know read machine code or punch cards?). C'est la vie.
- a pure binding crate, which exposes the C lib libraries API, and
- a wrapper library that performs some basic improvements
Stuff in the second category typically includes adding Drop impls to resources that need to be released, translating "accepts pointer + len" into "accepts slices" (or vice versa on return), and "check return value of C call and turn it into a Result, possibly with a stringified error".
All of those are also good examples of local reasoning about unsafety. If a C API returns a buffer + size, it's unsafe to turn it into a reference/slice. But if you check the function succeeded, you unsafely make the slice/reference, and return it from a safe function. If it crashes, you've either not upheld the C calls preconditions (your fault, check how to call the C function), or the C code has a bug (not your fault, the bug is elsewhere).
Yes, it's lots of fun. rust is Boring.
If I want to implement something and have fun doing it, I ll always do it in C.
there u can likely explore well the boundaries where rust does and does not work.
people have all kind of opinions. mine is this:
if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code.
a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C.
people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.
It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad.
For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years.
Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.
I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C.
Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.
There will be small niches leftover:
* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.
* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.
* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.
* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.
This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc.
> OS / Kernel - Nearly all of the relevant code is unsafe.
I think that characterization is rather exaggerated. IIRC the proportion of unsafe code in Redox OS is somewhere around 10%, and Steve Klabnik said that Oxide's Hubris has a similarly small proportion of unsafe code (~3% as of a year or two ago) [0]
> Browsers - Despite being born in a browser, Rust is unlikely to make any inroads.
Technically speaking, Rust already has. There has been Rust in Firefox for quite a while now, and Chromium has started allowing Rust for third-party components.
[0]: https://news.ycombinator.com/item?id=42312699
[1]: https://old.reddit.com/r/rust/comments/bhtuah/production_dep...
Google is transitioning large parts of Android to Rust and there is now first-party code in Chromium and V8 in Rust. I’m sure they’ll continue to write new C++ code for a good while, but they’ve made substantial investments to enable using Rust in these projects going forward.
Also, if you’re imagining the board of a multi-trillion dollar market cap company is making direct decisions about what languages get used, you may want to check what else in this list you are imagining.
> Based on our research, we landed on two outcomes for Chromium.
> We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++.
> We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation.
-- https://security.googleblog.com/2023/01/supporting-use-of-ru...
Also even though Rust would be a safer alternative to using C and C++ on the Android NDK, that isn't part of the roadmap, nor the Android team provides any support to those that go down that route. They only see Rust for Android internals, not app developers
If anything, they seem more likely to eventually support Kotlin Native for such cases than Rust.
I believe the Chromium policy has changed, though I may be misinterpreting: https://chromium.googlesource.com/chromium/src/+/refs/heads/...
The V8 developers seem more excited to use it going forward, and I’m interested to see how it turns out. A big open question about the Rust safety model for me is how useful it is for reducing the kind of bugs you see in a SOTA JIT runtime.
> They only see Rust for Android internals, not app developers
I’m sure, if only because ~nobody actually wants to write Android apps in Rust. Which I think is a rational choice for the vast majority of apps - Android NDK was already an ugly duckling, and a Rust version would be taken even less seriously by the platform.
The NDK officially it isn't to write apps anyway, people try to do that due to some not wanting to touch Java or Kotlin, but that has never been the official point of view from Android team since it was introduced in version 2, rather:
> The Native Development Kit (NDK) is a set of tools that allows you to use C and C++ code with Android, and provides platform libraries you can use to manage native activities and access physical device components, such as sensors and touch input. The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:
> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.
> Reuse your own or other developers' C or C++ libraries.
So it would be expected that at least for the first scenario, Rust would be a welcomed addition, however as mentioned they seem to be more keen into supporting Kotlin Native for it.
There are memory safety issues that literally only apply to memory on the stack, like returning dangling pointers to local variables. Not touching the heap doesn't magically avoid all of the potential issues in C.
Embedded Dev here and I can report that Rust has been more and more of a topic for me. I'm actually using it over C or C++ in a bare metal application. And I don't get where the no allocation -> no benefit thing comes from, Rust gives you much more to work with on bare metal than C or C++ do.
Memory safety applies to all memory. Not just heap allocated memory.
This is a strange claim because it's so obviously false. Was this comment supposed to be satire and I just missed it?
Anyway, Rust has benefits beyond memory safety.
> Rust is also too complex for smaller systems to write compilers.
Rust uses LLVM as the compiler backend.
There are already a lot of embedded targets for Rust and a growing number of libraries. Some vendors have started adopting it with first-class support. Again, it's weird to make this claim.
> Nearly all of the relevant code is unsafe. There aren't many real benefits.
Unsafe sections do not make the entire usage of Rust unsafe. That's a common misconception from people who don't know much about Rust, but it's not like the unsafe keyword instantly obliterates any Rust advantages, or even all of its safety guarantees.
It's also strange to see this claim under an article about the kernel developers choosing to move forward with Rust.
> High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
C++ and VHDL aren't interchangeable. They serve different purposes for different layers of the system. They aren't moving everything to FPGAs.
Betting on a garbage collected language is strange. Tail latencies matter a lot.
This entire comment is so weird and misinformed that I had to re-read it to make sure it wasn't satire or something.
> Anyway, Rust has benefits beyond memory safety.
I want to elaborate on this a little bit. Rust uses some basic patterns to ensure memory safety. They are 1. RAII, 2. the move semantics, and 3. the borrow validation semantics.
This combination however, is useful for compile-time-verified management of any 'resource', not just heap memory. Think of 'resources' as something unique and useful, that you acquire when you need it and release/free it when you're done.
For regular applications, it can be heap memory allocations, file handles, sockets, resource locks, remote session objects, TCP connections, etc. For OS and embedded systems, that could be a device buffer, bus ownership, config objects, etc.
> > Nearly all of the relevant code is unsafe. There aren't many real benefits.
Yes. This part is a bit weird. The fundamental idea of 'unsafe' is to limit the scope of unsafe operations to as few lines as possible (The same concept can be expressed in different ways. So don't get offended if it doesn't match what you've heard earlier exactly.) Parts that go inside these unsafe blocks are surprisingly small in practice. An entire kernel isn't all unsafe by any measure.
It's like saying python is complex becasue you have metaclasses, but you'll never need to reach for them.
> Rust is also too complex for smaller systems to write compilers.
Modern embedded isn't your grandpa's embedded anymore. Modern embedded chips have multiple KiB of ram, some even above 1MiB and have been like that for almost a decade (look at ESP32 for instance). I once worked on embedded projects based on ESP32 that used full C++, with allocators, exceptions, ... using SPI RAM and worked great. There's a fantastic port of ESP-IDF on Rust that Espressif themselves is maintaining nowadays, too.
only in interpreter mode.