Advancing Memory Safety

Original Article ↗ Hacker News Discussion ↗

Rust Evangelism & Backlash

  • Many see Rust advocacy as unusually intense, reminiscent of past functional‑programming evangelism (Haskell/Scala), and react against perceived “only the Rust way is valid” attitudes.
  • Some argue Rust advocates became loud because entrenched C/C++ users resist change; others say dogmatism and lack of nuance justify pushback.
  • Cultural clash is emphasized: young, online, meme‑driven Rust culture vs long‑time C/C++ developers; for some, opposition is more about “not liking Rust people” than the language.

Memory Safety, GC, and Runtimes

  • Debate over whether Java/C#/Go already provide “fast, safe” internet services; critics of Rust evangelism cite them as proven options.
  • Counterpoint: garbage collection is not the same as memory safety; GC languages’ safety also depends on runtimes (often in C/C++) and JIT correctness.
  • Others reply that runtime implementation details don’t directly make safe languages unsafe in the simple “use‑after‑free” sense, and runtimes are heavily tested.
  • Thread agrees memory safety is important but not the only security concern (e.g., injections, leaks, logic bugs).

Rust Ergonomics, Performance, and Web Dev

  • Some claim Rust is ergonomic without GC; lifetimes are mostly inferred, and typical code uses few explicit annotations.
  • Others find borrow checking and lifetime syntax intrusive, especially in high‑performance or complex sharing scenarios.
  • Use of Rc/Arc is discussed: non‑atomic Rc can be very cheap; Arc is costly on some architectures and must be used sparingly.
  • Opinions split on Rust for web dev:
    • Pro: good fit if team wants it; strong latency/throughput; viable even on very constrained hardware.
    • Con: ecosystem is young; async needs its own runtime; decision fatigue; GC’d languages like C#/Kotlin are often simpler and “good enough”.

Historical Parallels

  • Participants recall similar backlash to Java (slow, memory‑hungry, no generics early), Swift (missing Objective‑C features, disliked optionals), Kotlin (Java “is fine”), TypeScript (“unneeded complexity”), and Python (“not real programming”).
  • Widely noted pattern: the most‑used languages attract the most complaints.

C/C++ Attitudes and Tradeoffs

  • Several comments argue many C/C++ developers overestimate their memory‑management skill and feel threatened by Rust’s potential as a replacement.
  • Others stress that language choice must weigh ecosystem, training, development cost, and safety needs; there is no universally “objectively better” tool.

Carbon Language & Google

  • A Google reference to using Carbon for “more seamless interoperability with C++” to accelerate moves to memory‑safe languages prompted confusion.
  • Critics say Carbon currently prioritizes fast parsing and has only vague plans for memory safety.
  • A Carbon team member states the experiment must eventually demonstrate both strong C++ interop and memory safety; expectation is that C++ → Carbon will be a lower‑friction path to safety than C++ → Rust.
  • Carbon’s stance on excluding data races from its core memory‑safety model is questioned and described as still in flux.