r/rust • u/esiy0676 • 1d ago
Proficient in both Rust and C, when to pick C?
What would be your criteria for a new project (or parts of it) to be better fit for plain C in 2026?
55
u/matthieum [he/him] 1d ago
When regulations require a certified toolchain.
In safety critical industries -- automotive, airplanes, medical, ... -- certain pieces of code must be developed with certified toolchains. You'll find certified C toolchains for anything (at a price!), while the one Rust certified toolchain (Ferrocene) is only certified for a handful of standards.
43
u/rom1v 1d ago
If your project uses C dependencies, it's easier to use them directly than using outdated FFI crates or writing an FFI layer.
52
u/toxicsyntax 1d ago
As someone who’s day job it is to work on a large Rust application that calls into a bunch of C and C++ dependencies I strongly disagree.
Whether you use C or C-like Rust in unsafe blocks you will invariably have to think about ownership and access rules. Every time I have taken a shortcut and made something in plain C I have eventually come to regret it. It is just much nicer to deal with the unsafety and ownership hassle once, in the FFI bindings, and then have the Rust compiler deal with it for you from then on.
To OP: I would never start a new project in C. Only use for it I can see , is legacy code bases already completely in C.
5
u/Myrddin_Dundragon 1d ago
I agree completely. I'm in a giant C to Rust 'ship of theseus' port from a 17+ year old legacy code base. The main goal is removing all the global state and while it may be tempting to do a patch of an area with an ADT in C, it has always just been better to move that part to Rust directly and make an FFI.
8
u/sohang-3112 1d ago
Only reason left to use C instead of Rust is hardware support. There are still niche hardware targets especially in embedded targets for which C compilers like gcc can compile binaries, but Rust (which uses LLVM) can't. For others like Arduino, C++ is much better supported (especially when using the official Arduino IDE).
4
-14
14
u/CokieMiner 1d ago
When the rust compiler doesn't support the target, other wise you can do all the same things you do in c in rust, just reach out for unsafe if needed, better a to write unsafe rust than pure c cause the compiler remember you that the operation can have memory bugs and you are more carefull in those parts of your program.
3
u/rawlasso 1d ago
If you care about compilation time, or exact memory layout, C can be easier to work with. Sometimes you can save a lot of time and effort by mmaping and casting to a struct for some stuff. Rust doesn't guarantee any memory usage(like how much is used at any moment), but you can trivially constrain that in C(you know where all the mallocs are and when they happen).
1
u/QuiEgo 1d ago
Check out zero copy. It basically lets you do the same thing as casting to a struct in C. https://docs.rs/zerocopy/latest/zerocopy/
2
u/rawlasso 16h ago
Yeah there are always crates to do anything, the issue is compared with C they bloat the build(either binary size, dependencies, build time, etc.) Where writing the same in C is ~20 lines if you want to do a good job. The C isn't memory safe or any other nice thing Rust gives you, but for embedded, or gamejam/CTF/whatever time limited comp C has some mild advantages.
9
u/Puzzled-Landscape-44 1d ago
When half your Rust code is inside an unsafe block.
16
u/matthieum [he/him] 1d ago
Show me the code. No, seriously, show me the code.
The Redox micro-kernel is less than 10% of unsafe code. And there's little that's more low-level than a micro-kernel.
2
2
6
u/Plazmatic 1d ago
There's very little reason to write C at all, usually the duality is C++ vs rust.
Use C when you need to write an abi stable API that can be used between languages or when you need dynamic linking, basically if you need "glue" code.
Use C when you need to write an interpreter/language virtual machine that supports the largest possible number of platforms or similar use case.
Use C if you're targeting embedded and it doesn't have good Rust support and doesn't have good C++ support.
3
u/curiousEnt0 1d ago
For embedded, I’d generally pick C over Rust for now. For larger, bug sensitive projects, I’d prefer Rust.
6
u/strange-humor 1d ago
Until you get into RTOS type setup. Embassy starts to win for me over RTOS in space and management of the whole system.
-3
2
u/QuiEgo 1d ago
The really tough thing for me is RTOS options. There are some interesting options, but they still are young enough that support for (insert random microcontroller here) is all over the place. Most of the C ones have way more hours of runtime in real world systems. It feels like picking between Debian and… I don’t know, FreeBSD? Or someone’s hobby project OS (where the someone is a really gifted programmer doing this only in their spare time)? Like in theory there’s nothing wrong with them, and they probably will work, but it adds a lot of risk to a project.
0
u/devcexx 1d ago
I really like Rust, and embedded looks like a good use for it. But the reality is that you'll end up needing to use unsafe for some stuff, or use obscure macros for avoiding that, or need to assume runtime overhead. If you use unsafe, you kinda defeats part of the point of it so.... bfff not sure what would choose. Definitely if you need to support an architecture that is not officially supported by the Rust compiler properly (xtensa, for example), better to use C
11
u/_ChrisSD 1d ago
To me
unsafeis a major selling point of rust. Yes you need it a lot for some projects but it's much more narrowly scoped than C. It allows you to focus on the actually unsafe bits, create safe(r) wrappers, document the soundness requirements and comment onunsafe {}blocks to explain why they're sound.With enough discipline you can get somewhere close in C but it's very difficult and requires a lot of diligence (oops that innocuous looking
a + bis UB, etc).1
2
u/drink-more-rum 1d ago
unsafedoes not defeat the point of Rust. This is a fundamental misconception. The point of Rust is that it allows you to build safe APIs on top of unsafe code.2
u/devcexx 1d ago
Well, that is true, but it is not exempt of gotchas. The fact that you in your project take some minutes to make a supposedly safe API around unsafe code doesn't mean it is really safe -- you may have missed broken invariants, some missing tests, etc. If your project makes a constant overuse of unsafe, thinking that everything is 100% because you're sure you've considered all the possible conditions and situations, well, definitely your project will crash for a UB at some point.
Interrupt handling in embedded development is a common example of this. You may try to avoid using unsafe by leveraging some libraries like RTIC, but that's going to obscure your code under a pile of proc macros. I guess that's a tradeoff to make. But I guess that the idea of having small chunks of unsafe Rust code is better than have a huge C codebase where everything can be unsafe at any point still wins (?)
2
u/SailingToOrbis 18h ago
yeah but then there is no point of writing it when more than half of your code is unsafe
2
u/Nothing_from_void 1d ago
If you care about iteration time, compiling with C really does speed things up. On projects where I'm trying lots of things and experimenting I've found C to be significantly faster.
Just general SIMD/assembly inline I find it easier too, where it's going to be unsafe anyways
3
u/QuiEgo 1d ago
Schedule/business needs: Rust takes longer to write but gives higher quality code. Sometimes you need to hack something up and get it to market or make a prototype rapidly. Engineers hate this (how could you dare ship code you know may be lower quality, be riskier for security, etc???), but not all code projects are for fun.
You end up paying more for C long term and more for Rust up front. Sometimes it’s a business trade.
AI is making the “it takes longer to write Rust” problem go away.
11
u/matthieum [he/him] 1d ago
Rust takes longer to write but gives higher quality code.
Does it?
I mean, compared to GCed languages, I could maybe be convinced. Maybe.
But compared to C? Where you have the same ownership issues, without the language guardrails? I seriously doubt it.
I can write both C, C++, and Rust, and I was faster at writing Rust even when I had significantly less experience.
4
u/apadin1 1d ago
Yeah if I need a quick and dirty prototype I’m going to reach for Python, not C. At this point I only use C because I worked in embedded and most of the time C or C++ is the only option.
2
u/QuiEgo 1d ago
Sorry I should have clarified, I work in embedded so consider my response through that lense. For higher level software totally agree, I’d take python or rust over C in a heartbeat, it will be both faster to write and better
1
u/matthieum [he/him] 14h ago
I work in HFT, so our software spans low-level (own network stack) to high-level, and Rust works great throughout.
For embedded I have heard that frameworks like Embassy and real-time OS in Rust (can't remember the names) do a lot of the heavy-lifting (read
unsafe), and also offer abstractions which greatly reduce the risk of errors -- using ownership, for example -- which I would imagine contribute a lot to productivity. Hasn't this been your experience?1
u/Opposite-Breath7511 1d ago
The business tradeoff angle is spot on but I think the whole "AI makes Rust faster to write" thing only really plays out if you already know Rust well enough to spot when the AI is generating nonsense borrow checker workarounds
Ive seen people try to use AI as a crutch for Rust and they end up fighting the compiler even harder because the suggested code is subtly wrong in ways that are harder to debug than if theyd just written it themselves
If youre already proficient in both then the speed gap isnt as dramatic anyway, you just reach for what fits the constraints of the project. C when you need something dead simple with minimal dependencies, Rust when you know maintenance is gonna be a long term thing and youd rather the compiler catch stuff early
2
1
u/Front_Recording4360 1d ago
One case I keep running into: when the deliverable has to drop into someone else's locked-down build tree. Vendor BSP bring-up code, customer handoff modules, that sort of thing. Handing over a single C file that builds with whatever ancient GCC they already have is much easier than asking them to install a Rust toolchain and configure cross targets. Also the certified toolchain case others mentioned. Outside of those situations I pick Rust and keep the C-looking parts in small unsafe blocks with documented contracts.
1
u/programgamer 1d ago
If you want/have to use longjump at all. The sheer amount of automatic cleanup rust does is way more of a UB minefield than doing things in C and having to be explicit about everything no matter what.
1
u/adityazero 1d ago
If you want more job security around the project, choose C. AI is very good at writing rust.
1
u/addmoreice 1d ago
Regulations require a certified toolchain.
When hiring c programmers in the domain is easy and cheap while hiring rust programmers is hard and/or expensive.
When you need third party 'libraries' which call *into* your stuff instead of you calling them and they may routinely stomp all over the memory safety rules. ie, it's not a third party library, it's a third party framework.
When you have a huge amount of c code and c programmers in the company and it's something that can't be 'experimented' with and has a short deadline.
etc, etc, etc. Notice lots of these are non-technical issues? That's going to be the constant trend. Rust hits the mark to be just flat out better than C in many many many domains and the edges where it doesn't fit as perfect are usually where the benefits are still worth dealing with the slight annoyance. That being said, there are still plenty of reasons to keep using C and those reasons have very little to do with the technical issues. Network effects are serious man. serious!
1
u/brotcruncher 1d ago
If you want to make using your library as simple as possible.
C has interop to almost any other language, while Rust might require a Java Shop to first setup a Rust toolchain, tool ownership and so on.
0
u/NullOfSpace 1d ago
Something like the kernel of an operating system is probably a good example. There’s enough unsafe stuff that you need to do at that level that Rust doesn’t really buy you much. Even then I’d say write the core functionality in C and build on top of it in Rust.
5
u/________-__-_______ 1d ago edited 1d ago
The vast majority of a kernel can be written in safe Rust, so long as you design safe abstractions around the low-level primitives. I've written a toy microkernel before with less than 5% unsafe code, a number that'd be even lower on a monolithic kernel since device drivers aren't counted for me.
It's similar to the standard library: you need unsafe to implement things like memory allocation, but once you
Boxthat into a safe API the rest of the codebase doesn't need to worry about it.3
u/drink-more-rum 1d ago
That's not really true. Have you ever looked at kernel source code? Most of it is just regular logic, not bit-twiddling hardware directly.
-1
-4
-10
u/source-drifter 1d ago
when you have tokens choose rust otherwise choose c
6
u/esiy0676 1d ago
Why would you say THAT? :)
0
u/source-drifter 1d ago
well, i was just joking but rust kind of became the default language for ai driven development, so, yea, lol.
75
u/BusinessBandicoot 1d ago
When you for whatever reason cannot use rust. An example would be for ebpf programs where you need BTF maps, currently not possible with aya or rustc. Its been a minute so someone correct me if I'm wrong but it needs a specific unsized pointer representation the compiler can't support yet.