> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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.
41 comments
[ 2.8 ms ] story [ 70.6 ms ] threadWhat a shame. I would've read an article about this.
The landing page mentions Plan 9 as one of the systems.
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.
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.
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.
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.
Excited to see the compiler implementation when it's out -- a lot to learn from.
this is the wrong direction
(jk i read the readme)
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.
[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.
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.