Eurydice: a Rust to C compiler

Original Article ↗ Hacker News Discussion ↗

Prior art and related tools

  • Commenters note several existing Rust-to-C or alternative backends: rustc_codegen_clr (C/.NET), mrustc (minimal Rust compiler with C backend), an LLVM C backend revived by JuliaHub, and GCC’s gccrs front-end in C++.
  • Point made that many languages already interop with C, but Zig stands out by also being able to compile C/C++/ObjC directly with its own toolchain.

Motivations for Eurydice (Rust → C)

  • Main use case discussed: platforms where only a (possibly proprietary or ancient) C compiler exists, especially “weird” embedded targets and PLC environments.
  • Transpiling Rust to C lets these teams keep their vendor toolchains and still write in Rust.
  • Another suggested use: library authors shipping a C source distribution compiled from Rust so consumers don’t need a Rust toolchain.
  • Skeptics argue that if you want a C library you should just write C, and that debugging bugs in generated C will be painful.

C vs Rust: longevity, ABIs, and “zombie languages”

  • Broad agreement that the C ABI and C APIs (POSIX, SysV ABI, etc.) will be around for a very long time, even if C-as-a-language eventually declines.
  • Some expect C to outlive Rust; others say both will “live forever” in practice and can coexist, as in the Linux kernel.
  • Several compare C’s likely future to COBOL or Latin: widely used as an interface and for legacy, but not necessarily something people enjoy writing.
  • Counterpoint: some plan to keep writing new C for decades and genuinely prefer it.

Language tradeoffs and future evolution

  • Pro‑C arguments: simplicity, fast builds, stability, portability, small curated dependencies. Rust is seen by some as too complex, slow to compile, monomorphization-heavy, static-linking‑oriented, and “not pragmatic enough.”
  • Pro‑Rust arguments center on memory safety; critics of C point to unsafe strings and “just don’t make mistakes” memory management.
  • There’s a thought experiment about a language 10× better than Rust; some would gladly switch, others worry about churn, but consensus is that languages are allowed to die if better ones appear.
  • Alternative contenders mentioned: Zig, Jai (with skepticism about lack of public implementation), and Ada 95 (one commenter’s “10× better than Rust”).

Embedded, backends, and LLVM vs C

  • Some are surprised by choosing Rust→C instead of writing an LLVM backend for each target; others respond that:
    • Many vendors ship custom C compilers derived from old GCC; modifying those is cheaper than writing LLVM backends.
    • Writing LLVM backends is considered hard, poorly documented, and time‑consuming; a C backend “covers” many targets at once.

Cryptography and correctness worries

  • The article’s crypto example is criticized: constant‑time crypto is already hard in high-level languages; piping through two optimizing compilers adds risk.
  • One comment claims it’s impossible to fully guarantee timing behavior with current mainstream optimizing backends (LLVM/GCC), regardless of source language.

Tooling and ecosystem notes

  • Brief Nix vs Cargo discussion: Cargo is great for Rust dependencies; Nix is still valued for system‑wide toolchains (e.g., Ansible) and as checked‑in environment documentation.
  • Minor points: Rust’s integer-overflow panics only by default in debug; discussion of Rust’s aliasing advantages vs C with restrict; and the fact that lifetimes are enforced before lowering to forms that map cleanly to C.