Rust in 2025: Targeting foundational software

Original Article ↗ Hacker News Discussion ↗

Rust ABI and “foundational software”

  • Major subthread argues Rust lacks a stable, rich native ABI, which limits its use for OS-level APIs and dynamic libraries beyond extern "C".
  • Examples from other ecosystems: COM, Objective‑C/Swift ABIs, JVM/.NET, and Swift’s “monomorphization within a binary, dynamic dispatch across boundaries.”
  • Some want at least stable representations for enums/Option/Result/trait objects; others note that if this isn’t C-compatible, it mostly helps only Rust–Rust interop.
  • Counter‑arguments:
    • A fully stable ABI conflicts with Rust’s “zero-cost abstractions” and can reduce performance.
    • ABI should be opt‑in, not global.
    • For today’s needs, extern "C", dynamic linking, and crates like abi_stable/stabby are “good enough.”
    • For cross-language evolution, proposals like crABI or WASI Component Model are mentioned, but they’re incomplete or not yet native‑platform solutions.
  • Some argue an OS boundary should use explicit serialization (structs/protobuf/JSON) rather than freeze Rust’s internal calling conventions.

Specification, standards, and second compilers

  • One camp: if Rust aims to be industry‑foundational, it needs a formal, authoritative spec and multiple conforming implementations (for safety, liability, and competition).
  • Others: many widely used languages (Python, Ruby) effectively treat the reference implementation as the standard and function fine.
  • There is work on a specification and an alternative compiler (gccrs), but:
    • Critics say the formal spec RFC/process has stalled or been reset multiple times and remains non‑authoritative.
    • Defenders point to active work on the Reference and ongoing contributions, arguing progress is steady.
  • Debate over value: a spec as “contract” vs. risk of added process, burnout, and slowing development when current team is already resource‑constrained.

Language ergonomics and compile-time pain points

  • Frequently cited issues:
    • Self‑referential structs (e.g., holding both source text and AST).
    • Orphan rule friction; suggestions to relax it in binaries/workspaces, but implementation is nontrivial and risks breaking ecosystems.
    • Lack of partial self‑borrows on methods.
    • Large crates as single compilation units drive people to many tiny crates for compile-time reasons; some want automatic or finer‑grained partitioning.

Rust’s role, evangelism, and licensing

  • Some commenters perceive Rust advocacy as pushy, especially around “performance, reliability, and productivity” rhetoric; they want more demonstrated value and less dogma.
  • Others respond that Rust is already widely used (kernels, OS components, major platforms) and nobody is literally being forced.
  • Concern that Rust’s MIT/Apache bias plus “security” marketing will displace copyleft foundational software (invoking a “Gresham’s law” dynamic).

Interoperability, IPC, and cross-language calling

  • Discussion that cross-language calling is intrinsically complex; many attempts (COM, CORBA, RPC) have mixed success.
  • Some suggest message‑oriented, framed protocols over sockets or minimal C APIs with JSON/msgpack as a pragmatic cross-language “ABI.”
  • There’s interest in better C++ interop specifically to enable incremental migration, not just language‑agnostic component models.

GC, JIT, and zero-cost abstractions

  • One branch disputes characterizations of GC as inherently latency‑sensitive and abstraction‑averse:
    • Modern concurrent GCs can have near‑zero stop‑the‑world time; tradeoffs are more about memory footprint and warmup.
    • JITs can do speculative optimizations and deopt, sometimes outperforming AOT on certain patterns (example given with UTF‑8 encoding pipelines).
  • Another view: the original “zero‑cost abstractions” ideal is less universally critical today; high‑ and low‑level domains are increasingly separated.

Software engineering vs. formal engineering

  • Meta-discussion on whether insisting on specs is “real engineering” or overkill:
    • One side: all software is formal computation; specs are foundational, especially for safety‑critical contexts.
    • Other side: most real-world software has little formal spec and works acceptably; formalism is valuable but must be balanced against cost.