Wild – A fast linker for Linux

Original Article ↗ Hacker News Discussion ↗

A new Linux linker called Wild, written in Rust, aims to outperform existing tools like mold while eventually adding incremental linking, a feature long available on Windows but still missing in mainstream Linux linkers. Commenters examine how Rust’s safety and concurrency model may help manage the complexity of an incremental, highly parallel linker, but also note trade-offs around memory management, allocator choices, and integration with existing toolchains such as GCC and Rust’s own compiler. The conversation situates Wild within a broader push for faster build times—especially for large, LTO-heavy Rust and C++ projects—while acknowledging that it is not yet ready for production use.

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.