Wild – A fast linker for Linux

Original Article ↗ Hacker News Discussion ↗

Overview

  • Wild is a new fast ELF linker for Linux, written in Rust, with an eventual goal of fast incremental linking.
  • Discussion centers on: why Rust, incremental vs traditional linking, real-world performance, allocator choices, licensing, and ecosystem/tooling details.

Why Rust?

  • Proponents: Rust’s type system and borrow checker enable “fearless concurrency” and enforce invariants at compile time, making complex concurrent code (like incremental linking) more maintainable and less error-prone.
  • Some argue Rust’s safety lets developers use bolder, more aggressive optimizations without defensive coding.
  • Skeptics: incremental linking complexity is largely algorithmic and format-related, not language-dependent; C++ linkers (mold, lld) are already heavily parallelized.
  • There’s debate over whether Rust makes certain low-level hacks (e.g., deliberate leaks, custom allocators) harder; others counter that Rust supports arenas, ManuallyDrop, and explicit “no-free” patterns if desired.

Incremental Linking and Performance

  • Mold is very fast but intentionally non‑incremental; Wild’s differentiator is planned incremental, optimizing linking.
  • Some see lack of a production-ready incremental Linux linker as an embarrassing long-standing gap compared to MSVC.
  • Others note that for full, optimized builds with LTO, linker differences are dwarfed by LTO cost; fast linkers shine most in iterative builds.
  • Real-world reports: for modest projects, link time may be a small fraction of total build; for very large or many-binary builds, link time dominates and fast/incremental linkers matter.

Allocators and Memory Behavior

  • Discussion on bump/arena allocators vs “traditional” malloc: bump/GC-style allocators are fast and cache-friendly when you rarely free.
  • Mold reportedly benefits from faster allocators like mimalloc; Wild’s author reports no noticeable gain from such allocators, suggesting fewer allocations by design.

Tooling & Integration

  • Rust typically shells out to GCC/Clang as linker drivers because they know how to pull in CRT objects and platform-specific flags.
  • GCC’s -fuse-ld= only supports a fixed set of linkers; using Wild currently requires -B or custom GCC specs.

Licensing and Ecosystem

  • Mold’s move from AGPL to MIT reduced corporate friction; nonetheless, mold’s non‑incremental stance leaves room for Wild.
  • Thread revisits AGPL concerns in large companies and how relicensing typically requires contributor permission.

Miscellaneous

  • Wild is explicitly not production-ready yet; lacks support for linker scripts, so it cannot yet link the Linux kernel.
  • Some explore alternatives like dynamic linking, WASM-based “inner logic,” JIT linking, and custom executable formats.