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.
lispwitch 12 hours ago [-]
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
So the author made a Rust to C transpiler and immediately used it to transpile... the Rust compiler. I love it.
Animats 7 hours ago [-]
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.
taris2 13 hours ago [-]
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.
steveklabnik 11 hours ago [-]
This was done with mrustc, which produced byte identical output.
rcxdude 10 hours ago [-]
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.
wmanley 4 hours ago [-]
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.
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.
ronsor 13 hours ago [-]
> 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.
RustyRussell 4 hours ago [-]
Nobody who would code this up would be entirely sane. But I can't help thinking "these are my people" when I read this...
luke-stanley 46 minutes ago [-]
But did it Blender open the source?
cozzyd 11 hours ago [-]
I mean I get confused every time I use blender too but not to the point of losing fingers...
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.
afdbcreid 4 hours ago [-]
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.
Cadwhisker 13 hours ago [-]
> 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.
layer8 12 hours ago [-]
Finally we can rewrite all the Rust in C. ;)
avadodin 3 hours ago [-]
As long as we rewrite all the C++ in Rust first.
db48x 1 hours ago [-]
We should port it to Rust.
npalli 12 hours ago [-]
Rewrite in C is the new Rewrite in Rust.
keyle 4 hours ago [-]
GTA VI out in Rust before C++?
roflcopter69 3 hours ago [-]
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™
SpecialistK 12 hours ago [-]
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.
ivanjermakov 4 hours ago [-]
> 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.
Perz1val 4 hours ago [-]
> 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.
claudex 4 hours ago [-]
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.
Liquid_Fire 12 minutes ago [-]
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.
groos 12 hours ago [-]
As an ex C++ compiler developer, I heartily approve of this project. Kudos.
adithyassekhar 5 hours ago [-]
I'll wait for rustcrustc
micheleeet 3 hours ago [-]
Rust is finally memory safe enough to become C
Sharlin 3 hours ago [-]
"You have become the very thing you swore to destroy"
Imustaskforhelp 13 hours ago [-]
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.
lispwitch 12 hours ago [-]
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
hkalbasi 12 hours ago [-]
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.
afdbcreid 4 hours ago [-]
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.
Tiberium 13 hours ago [-]
I wonder how the performance looks like, because this can be interesting even for non-porting reasons ;)
adastra22 13 hours ago [-]
It is very unlikely that it would be faster.
gerdesj 13 hours ago [-]
Faster than what? Please finish your sentence.
lpribis 12 hours ago [-]
Faster than rustc (the main rust compiler written in rust). Obvious from the context.
gerdesj 12 hours ago [-]
[flagged]
keepupnow 12 hours ago [-]
Sonic
nxtfari 12 hours ago [-]
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.
moezd 8 hours ago [-]
Let Rust vs C battle commence with renewed haste!
fithisux 6 hours ago [-]
Kudos.
linzhangrun 11 hours ago [-]
Quite an interesting project, lol. I like the name `crustc` :)
casey2 8 hours ago [-]
Not to be confused with crust [1] the dialect of rust B [2][3] is written in.
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.
jolmg 6 hours ago [-]
Guideline:
> Don't post generated text or AI-edited text. HN is for conversation between humans.
jdw64 5 hours ago [-]
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.
jolmg 4 hours ago [-]
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...
You may be right. It's a really difficult problem.
jdw64 5 hours ago [-]
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
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.
More on the Rust bootstrapping process (2018): https://guix.gnu.org/blog/2018/bootstrapping-rust/
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.
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.
Excited to see the compiler implementation when it's out -- a lot to learn from.
What a shame. I would've read an article about this.
- 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.
The landing page mentions Plan 9 as one of the systems.
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.
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.
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.
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.
[1] https://github.com/tsoding/crust [2] https://github.com/bext-lang/b [3] https://www.nokia.com/bell-labs/about/dennis-m-ritchie/kbman...
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.
> Don't post generated text or AI-edited text. HN is for conversation between humans.
Probably because in East Asia, we tend to emphasize things with things like "xx" a lot.
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
this is the wrong direction
(jk i read the readme)