Rust’s worst feature

Original Article ↗ Hacker News Discussion ↗

Rust buffer initialization & missed optimization

  • Central issue: in idiomatic Rust, a buffer declared inside a loop as [0; 4096] is zero‑initialized every iteration; the compiler generally can’t hoist this out of the loop because that would change observable behavior.
  • Programmers can manually move the buffer out or add a nested scope, but several commenters argue the compiler should avoid forcing such refactors for performance, especially when inefficiency is hidden behind abstractions (e.g., A::init_from_file called in a loop).
  • Others counter that in small, clear loops code organization matters less than performance, but in real code scopes and borrows often dictate that buffers live exactly within loop bodies.

Uninitialized memory, safety, and undefined behavior

  • Rust must assume that read/FFI/system calls may read from the buffer, so passing uninitialized memory via a safe &mut [T] is disallowed; APIs like BorrowedBuf and MaybeUninit encode “this region may be uninitialized, these bytes become initialized.”
  • There is debate over whether reading uninitialized memory is “truly unsafe” in practice; some argue it’s just an arbitrary but deterministic RAM value, others point to Linux’s MADV_FREE and allocator behavior where an unread, unwritten page can change contents, breaking the “two reads same value” guarantee Rust and LLVM rely on.
  • C/LLVM semantics and trap/invalid representations (e.g., for bool) further complicate “just treat everything as [u8]”; only integer types like u8 are guaranteed to have all bit patterns valid.

Compiler analysis and API design

  • Several commenters suggest more advanced static/data‑flow analysis to detect buffer reuse patterns and hoist initialization, but others note that:
    • The compiler generally optimizes per‑function, not whole‑program/FFI/systemcall behavior.
    • Encoding “this call only writes N bytes” requires richer contracts or explicit types, essentially what BorrowedBuf is trying to provide.
  • Ideas floated include write‑only references, better traits for “any bit pattern,” and more ergonomic APIs that return slices instead of lengths.

Library stability vs abandonment

  • Side discussion: is using “apparently abandoned” crates bad?
    • One side equates inactivity with unmaintained, bug‑ and vuln‑prone code.
    • Others argue many libraries are simply “finished”; lack of commits doesn’t imply new bugs, though OS/platform evolution and external APIs can still break old code.
    • Distinction drawn between “stable, with issues monitored” and “truly abandoned with piling unresolved issues.”

Reactions to the article & Rust process

  • Multiple commenters find the “worst feature” framing hyperbolic and view this as an important but narrow low‑level concern.
  • General consensus that Rust’s stabilization process is cautious and that features like BorrowedBuf are still “baking”; constructive feedback belongs on the tracking issue.
  • Some prefer a small amount of well‑reviewed unsafe code over complex type‑level workarounds; others see the current direction as rightly pushing unsafety to carefully designed abstractions.