alt.hn

7/2/2026 at 10:57:35 PM

crustc: entirety of `rustc`, translated to C

 https://github.com/FractalFir/crustc

by Philpax

7/2/2026 at 11:48:39 PM

> For the past 3 years, I have been working on compiling Rust to C. .. This is, by my count, the 14th attempt: cilly

Gotta respect the dedication to a niche interest.

> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support.

I remember reading about the bootstrapping question, how it typically requires a Rust compiler to build the Rust compiler from source. https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif...

Oh, but I see there's a C++ implementation of the Rust compiler. https://github.com/thepowersgang/mrustc

Anyway, this part sounds useful too, that crustc can compile across network and devices.

> You build a small C server on your Blorbo OS, run rustc on some normal platform like Linux, and let cilly talk over the wire.

by lioeters

7/3/2026 at 12:51:22 AM

Guix uses mrustc for bootstrapping Rust, as required for compiler packages; it's a really impressive project and has worked well in that role for some time. This new project is interesting for other reasons though, because mrustc is targeted at the de fact "subset" of Rust in use by rustc at any given time. This looks like it could have broader applications, like compiling Rust programs for platforms not supported by LLVM. If it really targets ANSI C (C89 or so), that's potentially many more platforms than are possible with ordinary rustc

More on the Rust bootstrapping process (2018): https://guix.gnu.org/blog/2018/bootstrapping-rust/

by lispwitch

7/3/2026 at 4:49:56 PM

> compiling Rust programs for platforms not supported by LLVM

For this, gcc-rs[1][2] is the most promising candidate.

[1] https://rust-gcc.github.io/

[2] https://github.com/Rust-GCC/gccrs

by xvilka

7/3/2026 at 10:09:52 PM

Gccrs is valuable for various reasons (bootstrapping, refining the spec, etc), but for the main purpose of "compiling to targets supported by gcc but not llvm", it's definitely not as promising as https://github.com/rust-lang/rustc_codegen_gcc. It's a rustc backend, at the same level as llvm or cranelift, it's much further along than gccrs (already available as a rustup component and can compile any rust code) and will not suffer from lagging behind rustc.

But OP has wider ambitions: the real niche targets are supported by neither gcc nor llvm. A rust-to-c transpiler that can adapt to weird C compilers should have a very wide reach.

by moltonel

7/3/2026 at 5:49:51 PM

But what about platforms that even GCC doesn't support well? I'm thinking mostly retro stuff like 16-bit x86.

by Narishma

7/3/2026 at 5:47:51 PM

I might have seen that Bootstrapping Rust article, how interesting. I've been curious about Guix for a while, one of these days I need to dive in and explore deeper. I really enjoyed their article on full-source bootstrap, it's relevant now more than ever.

Building from Source All the Way Down - https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

by lioeters

7/3/2026 at 12:11:31 AM

So the author made a Rust to C transpiler and immediately used it to transpile... the Rust compiler. I love it.

by zadikian

7/3/2026 at 5:52:25 AM

It makes sense as a porting tool, if you need to port the Rust compiler to some target that has a C compiler.

But it doesn't mean rustc generates code for that target, only that you can run it there. You'd still have to teach LLVM about the target. Although that might already have been done.

It's not that useful for retro computers because the Rust compiler needs too much memory for most machines of the 32-bit era.

by Animats

7/3/2026 at 3:50:12 PM

As far as I know, ISO c++ is no better than microsoft rust.

It is said microsoft rust syntax is on the same brain damage complexity level than ISO c++. That, and I don't even talk about the technical cost of its runtime (not far from the toxicity of a jvm?)

by sylware

7/3/2026 at 4:02:00 PM

What is Microsoft rust? I’ve never heard of such a thing. Or did I miss the joke?

by slashdev

7/3/2026 at 4:23:19 PM

I don't think there's a joke, this commenter seems to believe Rust is controlled by Microsoft

by hmry

7/3/2026 at 7:10:14 PM

Don't think I am alone to know that...

by sylware

7/3/2026 at 12:35:14 PM

> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support.

If you're going to go to all this effort for an old target though, wouldn't the effort be better spent on making it an LLVM target? Then you'd get Rust and a bunch of other languages for free.

But maybe there are required parts of the LLVM IR that make this undesirable for certain targets, maybe requiring specific hardware features, I don't know. I guess also WASM-as-IR is a possible way to go. (Is that a thing?)

Edit: sorry I see that this point was already raised in this thread by ivanjermakov. Ignore.

by radarsat1

7/3/2026 at 5:44:06 PM

> WASM-as-IR .. (Is that a thing?)

Yes, actually I've heard of some projects compiling a language to Wasm, then using wasm2c to translate to C.

https://github.com/WebAssembly/wabt/blob/main/wasm2c/README....

The Zig project does something similar for their bootstrapping process with a custom wasm2c implementation with just the features they need.

https://github.com/ziglang/zig/blob/master/stage1/wasm2c.c

I get the feeling this is an underappreciated technique with more potential.

by lioeters

7/2/2026 at 11:48:45 PM

Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor?

Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.

by taris2

7/3/2026 at 1:24:32 AM

This was done with mrustc, which produced byte identical output.

by steveklabnik

7/3/2026 at 2:34:30 AM

Better than that, you can get a bootstrapped rust from the Guix project, which has bootstrapped its entire system from source code from only a tiny verifiable binary.

by rcxdude

7/3/2026 at 8:48:51 AM

It's not diverse in that case - it's the same compiler source compiled to binaries twice - it's just that with one compiler you've gone via a C intermediate representation. For the purposes of diversity it's the same as compiling rustc with the cranelift/gcc backend.

by wmanley

7/3/2026 at 1:54:59 PM

From a "trusting trust" point of view, compiling rustc-translated-to-C with a C compiler (and comparing the result to normally-compiled rustc) is a valid demonstration, because we're again starting from code and can eliminate the possibility of a binary-resident compromise.

The actual issue here is that the translation was done using a rustc backend, and therefore an existing rustc binary which could be compromised and inject a "if (user=="wmanley") {...}" that isn't present in the original Rust code. If cilly was completely standalone (like mrustc), or if you had a rustc+cilly build you trusted, there would be no issue.

by moltonel

7/3/2026 at 1:18:28 AM

This reminds me of https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

by swalberg

7/3/2026 at 4:13:54 AM

The sole and entire purpose of Diverse Double-Compiling is addressing Thompson's Trusting Trust: https://dwheeler.com/trusting-trust/

by laughinghan

7/3/2026 at 11:49:48 AM

I didn't know there's a solution, thanks!

by FergusArgyll

7/3/2026 at 2:16:15 AM

Reflections on Trusting TRust.

by lioeters

7/3/2026 at 2:37:08 AM

tRust

by jagged-chisel

7/3/2026 at 12:48:15 AM

Awesome idea!

by amir734jj

7/2/2026 at 11:48:50 PM

Very cool. At first, I thought it was yet another LLM-generated demo, but no: original work of art. Super cool. Transpiling into C does seem easier than LLVM IR, and letting GCC optimize seems like this might actually work.

Excited to see the compiler implementation when it's out -- a lot to learn from.

by levkk

7/2/2026 at 11:37:55 PM

> I put my left hand in a blender. The blender won. (Still have all my fingers, just some stitches). I will not elaborate further.

What a shame. I would've read an article about this.

by ronsor

7/3/2026 at 8:52:25 AM

Nobody who would code this up would be entirely sane. But I can't help thinking "these are my people" when I read this...

by RustyRussell

7/3/2026 at 4:12:01 PM

He wrote 14 Rust to C compilers. Sanity has gone out of the window already.

by gpvos

7/3/2026 at 12:57:24 AM

I mean I get confused every time I use blender too but not to the point of losing fingers...

by cozzyd

7/3/2026 at 11:41:15 AM

But did it Blender open the source?

by luke-stanley

7/3/2026 at 2:32:51 AM

I desperately want to know more.

by iwassayinbourns

7/2/2026 at 11:56:01 PM

Wait, I thought LLVM had a C backend which could be used for the purpose of transpiling Rust to C? Turns out not for a long time, but now maybe again: https://discourse.llvm.org/t/re-ann-llvm-c-backend-still-abl...

by ahartmetz

7/3/2026 at 6:39:51 AM

This approach is harder than you might imagine. LLVM can do a lot of things that don't map to C language constructs. You cannot generally roundtrip arbitrary LLVM IR through some C representation. You can emulate most things, but you won't necessarily get the same LLVM IR in the other end.

by simonask

7/3/2026 at 8:03:08 AM

FWIW, Rust can also do a lot of things that do not easily map to C (at least standard C) constructs. For example:

- You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first.

- Signed integer overflow is UB in C, defined to wrap/panic in Rust.

- Type-based alias analysis is a big one, does not exist in Rust.

by afdbcreid

7/3/2026 at 1:59:37 PM

> You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first.

Indeed specifically Rust defines that pointer comparisons are done by address, whereas C doesn't specify what the rules are exactly. This gets sticky if the pointer was invalidated (e.g. you free'd the memory it was pointing at). Rust says - as you might expect - that you can still compare this invalid pointer to another pointer (which may or may not still be valid and indeed might be a valid pointer to the same address!) because we're only comparing the address - but C++ says you mustn't do that and I believe C has the same rule.

> Signed integer overflow is UB in C, defined to wrap/panic in Rust.

This doesn't feel like an interesting difference. C made a weird choice, which was maybe convenient for the usual Worse Is Better reasons 50+ years ago. LLVM doesn't care about that choice, LLVM can cheerfully simulate this behaviour in C if you want that.

> Type-based alias analysis is a big one, does not exist in Rust.

This also doesn't feel relevant but I guess I'm interested in why you think it would make "a big" difference?

Edited: I confirmed C11 has "pointer zap" which is the behaviour I described above, and I believe C23 also still has pointer zap although paulmck and co. are trying to get rid of it or do something on this topic in C2y.

by tialaramex

7/2/2026 at 11:38:53 PM

> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support. There are still some systems out there that don't support Rust but support C.

The landing page mentions Plan 9 as one of the systems.

by Cadwhisker

7/3/2026 at 12:15:17 AM

Finally we can rewrite all the Rust in C. ;)

by layer8

7/3/2026 at 9:45:20 AM

As long as we rewrite all the C++ in Rust first.

by avadodin

7/4/2026 at 8:39:41 AM

Starting by the compiler infrastructure rustc depends on.

by pjmlp

7/3/2026 at 8:29:00 AM

> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support

Wouldn't it be easier to add old hardware support to LLVM/GCC instead? I adore the project scale and determination, but for this goal extending existing projects seems more logical than building a language translator.

by ivanjermakov

7/3/2026 at 8:52:57 AM

> Wouldn't it be easier to add old hardware support to LLVM/GCC instead?

No, in fact it's much, much harded. You have no idea of the scope. I have no idea of the scope. Nobody does. There are obscure machines we've never heard about and there are C compilers for them. Targeting and supporting them from modern toolchains is a fool's errand.

by Perz1val

7/3/2026 at 1:15:33 PM

rust to c supports infinite platforms that already have a c compiler by implementing a single rust to c program

on the other hand, porting llvm to an infinite number of platforms requires an infinite amount of work

so, it is less work this way

by jitl

7/3/2026 at 8:42:53 AM

Some architecture lacks documentation, if you have a working C compiler, it's easier to use it than working on a compiler to target it.

by claudex

7/3/2026 at 12:15:35 PM

Presumably you still need a C++ compiler for LLVM itself though. Or... a C++ to C translator.

Edit: On second thought, that's only needed if you want to run rustc itself on the old hardware, which is probably not super useful given the main reason you would need to do this is if LLVM can't target that hardware.

For building code written in Rust for such old hardware, this would be sufficient.

by Liquid_Fire

7/3/2026 at 12:55:48 AM

Rewrite in C is the new Rewrite in Rust.

by npalli

7/3/2026 at 8:26:31 AM

GTA VI out in Rust before C++?

by keyle

7/3/2026 at 9:47:56 AM

Wake me up when consoles officially support Rust. Until then there's no real way around C/C++ if you want to publish a real game to real consoles. But there's https://akaganite.com so it might become possible soon™

by roflcopter69

7/3/2026 at 3:47:25 PM

They don’t need to “officially support” Rust in order to ship code written with Rust. Just target the applicable architecture and ABI. It’s a lot easier now that the ABI’s are mostly standard now too.

Source: I wrote a compiler and runtime that ran .NET code (AoT compiled with LLVM) on PS3/Xbox360/Wii and shipped a few games with it.

by maximilianburke

7/4/2026 at 8:46:48 AM

As does Capcom with .NET and others.

Still it is a matter of sinergy and culture sharing across studios, hence why despite gains achieved by engines like Unity, the huge success made by Minecraft, or Android owning a big chunk of casual mobile games market, most studios end up using C, C++ and the engines that get tier 1 support from platform owners.

The culture in the games industry has always been that IP is what matters, the pain points getting it out there not only are secondary, they are also proudly used at some random GDC talk.

by pjmlp

7/4/2026 at 9:14:22 AM

Then why aren't there any public statements about games written in Rust being officially published on consoles? I know that it's technically possible but that does not help you when Nintendo, Sony or Microsoft just say "no" to you because you misuse their toolchains.

by roflcopter69

7/4/2026 at 4:33:02 PM

Who did they say no to?

by maximilianburke

7/3/2026 at 12:29:05 AM

As an ex C++ compiler developer, I heartily approve of this project. Kudos.

by groos

7/3/2026 at 12:14:06 AM

I wonder if this could be used in PPC Mac OS X, where LLVM isn't supported and most graphical applications need to use GCC 4 with Apple's SDK.

by SpecialistK

7/3/2026 at 6:58:27 AM

I'll wait for rustcrustc

by adithyassekhar

7/3/2026 at 5:43:54 PM

If I understand this correctly, you could run this compiler on iPadOS (since it's plain C). But you cannot mark it's output executable, since that would require JIT entitlement.

by Archit3ch

7/3/2026 at 5:46:18 PM

Target WASM then

by ronsor

7/3/2026 at 5:56:27 PM

Sure, that works. Caveats:

1. Your frontend needs to support emitting WASM. Ok for Rust, not for every language out there.

2. 2x-4x performance overhead.

by Archit3ch

7/2/2026 at 11:48:46 PM

This could be used within https://bootstrappable.org/projects.html to make bootstrappability of rust incredibly much easier other than the previous route of OCaml and other things.

I know some folks within the bootstrappable OS projects community are on Hackernews and I hope that they could take a look at this. I feel as if this project could drastically shrink down the efforts needed to get a working rust compiler in a bootstrappable manner.

by Imustaskforhelp

7/3/2026 at 12:56:32 AM

mrustc (a handwritten Rust compiler in C++) is already used for that in Guix and likely other distros: https://guix.gnu.org/blog/2018/bootstrapping-rust/ This would have other benefits though, as it's both a second bootstrapping path and could potentially compile Rust programs for platforms not supported by LLVM

by lispwitch

7/3/2026 at 12:26:06 AM

Not really. This C code is more like a binary and compiler artifact than a source code. So it won't match the standards of bootstrap.

by hkalbasi

7/3/2026 at 8:04:58 AM

Depending on what your goal is. If it is eliminating trusting trust attacks, yes this is no enough. But more commonly you only want to compile rustc for a platform it was never compiled on, and for that this project is definitely enough.

by afdbcreid

7/3/2026 at 11:25:54 AM

We should port it to Rust.

by db48x

7/2/2026 at 11:22:42 PM

I wonder how the performance looks like, because this can be interesting even for non-porting reasons ;)

by Tiberium

7/2/2026 at 11:44:13 PM

It is very unlikely that it would be faster.

by adastra22

7/2/2026 at 11:47:15 PM

Faster than what? Please finish your sentence.

by gerdesj

7/3/2026 at 12:03:52 AM

Faster than rustc (the main rust compiler written in rust). Obvious from the context.

by lpribis

7/3/2026 at 12:33:50 AM

[flagged]

by gerdesj

7/3/2026 at 12:22:30 AM

Sonic

by keepupnow

7/3/2026 at 3:02:20 PM

What sort of hardware would this be useful for?

by kube-system

7/3/2026 at 12:35:07 AM

this is really cool but it seems very unlikely that someone targeting an exotic system not supported by rust (mostly embedded and ancient mainframe targets) would be willing to trust a beta transpiler to not inject any bugs or leaks in the process of turning rust to c. nevertheless, very cool.

by nxtfari

7/3/2026 at 9:04:05 AM

Rust is finally memory safe enough to become C

by micheleeet

7/3/2026 at 9:06:06 AM

"You have become the very thing you swore to destroy"

by Sharlin

7/3/2026 at 3:42:13 PM

The real salvation is assembly written software with a wordwide non-IP-locked ISA (for instance RISC-V). Then very high language interpreters would be written directly in such assembly.

by sylware

7/3/2026 at 4:47:59 AM

Let Rust vs C battle commence with renewed haste!

by moezd

7/3/2026 at 2:09:50 PM

There are discussions of round-trip between Rust and C;

Would this be useful for this too?

From https://news.ycombinator.com/item?id=46265855 :

> To better port C to Rust: 3C (Checked C), c2rust, Crown ownership analysis, RustMap, c2saferrust (LLM), Laertes

C -> Checked C -> Rust

Because Checked C will annotate the raw and other C pointers first.

by westurner

7/3/2026 at 6:24:11 AM

Kudos.

by fithisux

7/3/2026 at 1:24:01 AM

Quite an interesting project, lol. I like the name `crustc` :)

by linzhangrun

7/3/2026 at 7:29:33 AM

[dead]

by valentynkit

7/3/2026 at 1:21:08 AM

[dead]

by CurbStomper

7/3/2026 at 12:38:55 PM

[dead]

by sylware

7/3/2026 at 2:19:10 PM

[flagged]

by icase

7/3/2026 at 4:17:56 AM

The most interesting part of this to me is not “Rust to C” by itself, but the fact that it widens the pool of people who can help debug portability problems.

There are relatively few people who understand Rust’s compiler internals, LLVM backends, and obscure target support deeply. But there are many engineers who understand C compilers, ABIs, linkers, makefiles, cross-compilation, old operating systems, and weird platform-specific compiler behavior.

If Rust can be lowered into target-specific C, then some problems stop being exclusively “Rust compiler problems” and also become C toolchain problems. That means more people can inspect the generated C, build failures, linker errors, ABI mismatches, and compiler-specific behavior.

C is obviously not a magic portability layer. ABI details, integer widths, alignment, TLS, aliasing, and undefined behavior still matter. But as an ecosystem boundary, C gives many more engineers a way to participate in debugging and porting work.

I think that social/maintenance aspect may be more important than the language translation itself.

by unjuno

7/3/2026 at 5:59:18 AM

Guideline:

> Don't post generated text or AI-edited text. HN is for conversation between humans.

by jolmg

7/3/2026 at 7:18:15 AM

I saw the reply, and it's not GenAI text. It's just that in the process of translation, people usually use machine translation or LLM translation. The problem is the vocabulary we East Asians use. I experience this issue too.

Probably because in East Asia, we tend to emphasize things with things like "xx" a lot.

by jdw64

7/3/2026 at 7:59:34 AM

I thought that may be the case. I shared the guideline so they'd know the likely reason all their comments die immediately.

However, their comments are consistently long, so it may be GenAI after all. Their last comment in particular...

https://news.ycombinator.com/item?id=48771339

by jolmg

7/3/2026 at 8:02:02 AM

You may be right. It's a really difficult problem.

by jdw64

7/3/2026 at 7:22:39 AM

I think you're probably using DeepL or some other AI translation. When you use DeepL, most sentences become flat and end up being judged as GenAI. I also used DeepL to communicate on Hacker News in the early days.I had a similar problem

by jdw64

7/3/2026 at 12:25:31 AM

i believe the author is confused

this is the wrong direction

(jk i read the readme)

by dangoodmanUT

7/3/2026 at 3:47:09 PM

Nope, and c++ should get the same thing.

But we now all know rust is microsoft and c++ ISO. I don't think we can trust much more ISO than microsoft to produce less feature creep over the currently known planned obsolescence cycle of 5-10 years.

by sylware