Migrating from Go to Rust

Original Article ↗ Hacker News Discussion ↗

Rust’s growing appeal as a replacement for Go in backend and systems work is prompting close comparisons of their trade‑offs: Rust offers stronger compile‑time guarantees, richer types, and better protection against data races and nil-style bugs, while Go wins on faster builds, a large battle-tested standard library, and simpler concurrency via goroutines. Many argue Rust’s safety and performance are worth the added complexity, especially for critical services, but others see Go as more practical for typical web backends, where GC pauses and lower-level control rarely dominate real-world costs. Several comments also note that heavy use of third-party crates in Rust raises supply-chain and maintenance concerns, and that AI-assisted coding may change how teams weigh Rust’s stricter compiler against Go’s ease of reading and iteration speed.

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.