Notes by djb on using Fil-C

Original Article ↗ Hacker News Discussion ↗

What Fil-C Is and Where It Fits

  • Discussed as a “fanatically compatible” memory-safe C/C++ implementation that catches all memory-safety errors via GC + capabilities.
  • Seen primarily as a tool for existing C/C++ code: rebuild large userlands (Debian, NixOS, Omarchy) without rewrites, especially for network-facing, root-privileged or long-lived infrastructure.
  • Several commenters stress it’s not mainly for greenfield code; for new work, people still lean toward Rust, Go, C#, Nim, etc.

Performance, GC, and Memory Overhead

  • Benchmarks cited: Fil-C often runs 1–4× slower than clang on crypto microbenchmarks; some reports of ~2× slowdown on array-heavy code, and ~5× on SQLite.
  • Binary size and RAM can be ~10× larger in some cases (e.g. bash); Rust is noted as similarly bad on binary size, though often better on RAM.
  • Debate over GC: some see any GC as unacceptable overhead; others argue modern GCs can be competitive and that many C programs are I/O-bound anyway.
  • Fil-C’s GC is described as sophisticated, with mechanisms to avoid classic GC-induced leaks when free() is used carefully.

Security Model and Limitations

  • Strong enthusiasm for being able to run a whole C userspace with deterministic panics on use-after-free and many other memory errors.
  • Comparison with CHERI: both need GC-like quarantine to prevent temporal bugs; Fil-C uses object headers and capability revocation, CHERI uses hardware tags.
  • Some limits noted: intra-object overflows (e.g., overwriting a field inside a struct) are not prevented; Fil-C zeroes malloc’d memory but doesn’t “magically” fix all logic bugs.
  • Use for cryptographic code is attractive but requires re-evaluating constant‑time properties under the new runtime.

Interoperability and Deployment

  • Current design disallows in-process mixing of Fil-C and classic C; you must rebuild everything or isolate unsafe code via separate processes/RPC.
  • This is seen as both a strength (no escape hatches) and a practicality issue compared with, say, adding Rust modules to a C codebase.
  • Suggested uses include: production builds for security-sensitive daemons, or as a powerful sanitizer-like tool in testing.

Fil-C vs Rust, WASM, and “Rewrite Culture”

  • Ongoing tension: “rewrite in Rust” vs “recompile with Fil-C” vs sandbox with WASM vs “do nothing”.
  • Some argue rewrites of mature utilities in Rust are low ROI and add new bugs; Fil-C preserves battle-tested semantics while improving safety.
  • Others counter that most memory bugs appear in new code, so changing languages (Rust, etc.) is still important, with Fil-C mainly a mitigation for legacy stacks.