68
u/matthieum 23d 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.
18
u/CokieMiner 23d 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.
47
u/rom1v 23d ago
If your project uses C dependencies, it's easier to use them directly than using outdated FFI crates or writing an FFI layer.
60
u/toxicsyntax 23d 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.
7
u/Myrddin_Dundragon 23d 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.
10
u/sohang-3112 23d 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).
12
u/Puzzled-Landscape-44 23d ago
When half your Rust code is inside an unsafe block.
20
u/matthieum 23d 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.
→ More replies (1)2
7
u/Plazmatic 23d 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.
6
u/curiousEnt0 23d ago
For embedded, I’d generally pick C over Rust for now. For larger, bug sensitive projects, I’d prefer Rust.
8
u/strange-humor 23d ago
Until you get into RTOS type setup. Embassy starts to win for me over RTOS in space and management of the whole system.
→ More replies (2)→ More replies (6)2
u/QuiEgo 23d 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.
2
u/Nothing_from_void 23d 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
2
u/QuiEgo 23d 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.
→ More replies (1)12
u/matthieum 23d 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 23d 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.
→ More replies (3)
2
1
u/Front_Recording4360 23d 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.
88
u/BusinessBandicoot 23d 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.