Migrating from Go to Rust

Original Article ↗ Hacker News Discussion ↗

Rust vs Go: Stdlib, Dependencies, and Supply Chain Risk

  • Many contrast Go’s large, “batteries-included” stdlib with Rust’s small core plus many crates.
  • Several complain Rust projects accumulate huge transitive dependency graphs (e.g., simple apps pulling in 100–400 crates), raising security and maintenance concerns.
  • Others argue stdlib vs crate quality is orthogonal; what matters is resources and oversight. A big stdlib can also ossify or accumulate legacy APIs.
  • Some want curated, inter-compatible crate “clusters” (like Boost in C++) or stronger trust mechanisms rather than relying only on stdlib.

Error Handling and Safety Guarantees

  • Rust’s Result/Option types and the ? operator are praised for making error and null handling explicit and compiler-checked; whole classes of nil/data-race bugs reportedly disappear after migrations.
  • Go’s explicit if err != nil is seen as verbose but straightforward and well supported by linters. Some say it “gets out of the way”; others call it noisy and easy to ignore.
  • Rust’s ecosystem of error crates (thiserror, anyhow) divides opinion: some see a coherent model around std::error::Error, others experience confusion over multiple “frameworks” and boilerplate.

Performance, GC, and Concurrency

  • For typical web backends, many agree Go is “fast enough”; Rust tends to win on latency tails, memory footprint, and avoiding GC pauses, which matter for high‑throughput or latency‑sensitive systems.
  • Go’s managed runtime and GC are valued for simplicity; some argue most app developers shouldn’t pay Rust’s ownership/borrow-checker complexity.
  • Rust’s concurrency model (no data races in safe code) is seen as a big win over Go’s goroutines + race detector, but it can be harder to use (async, lifetimes).

Web Backends, Ecosystems, and Tooling

  • Several prefer Go for web services due to mature, widely used stdlib and libraries, simple deployment, and fast compiles; frameworks are often shunned in favor of small libraries.
  • Rust’s web ecosystem (e.g., Axum) is praised for strong typing and ergonomics, but async complexity, slower builds, and reliance on many crates are recurring complaints.
  • Some note Rust’s tooling (rust-analyzer, cargo) is slower and heavier than Go’s (go build, gopls).

LLMs, “Agentic Coding,” and Language Choice

  • There is disagreement on how LLMs shift the tradeoffs:
    • One camp says Rust’s strong types and clear compiler errors make it ideal for agents; compile-time guarantees reduce what humans must review.
    • Another argues Rust’s slower builds and more complex syntax increase token cost and turnaround time; Go compiles and iterates faster and is easier for humans to review AI-generated code.

Migration Economics and When Rust Makes Sense

  • Several advise: keep profitable Go systems in Go; only migrate hotspots or critical infrastructure where Rust’s guarantees and performance clearly matter.
  • Others report successful Go→Rust migrations (e.g., for concurrency bugs, deterministic testing) but stress it’s a tradeoff: safety vs iteration speed and team familiarity.

Meta: Article Tone and AI Assistance

  • Multiple commenters suspect the original article is AI-assisted due to style and phrasing, but generally still find the analysis useful.