Why Go?

Original Article ↗ Hacker News Discussion ↗

Context: Porting, Not Rewriting

  • The team frames this as a port of the existing JS/TypeScript compiler, not a greenfield rewrite.
  • Priority is preserving semantics and even code structure so changes can be mirrored between JS and native versions.
  • Languages that require rethinking memory management, data structures, or polymorphism are seen as better for rewrites than ports.

Why Go Was Chosen (Per the Thread)

  • Idiomatic Go (functions over classes, simple structs, explicit data passing) is described as very close to the current TS checker style, which uses no classes and is mostly pure-ish functions over data.
  • This structural similarity makes the port “nearly indistinguishable” from the original code, easing maintenance and contributor onboarding.
  • Go delivers native binaries with an embedded runtime and fast startup, avoiding the friction of requiring a separate runtime installation.
  • Internal experiments reportedly found Rust and Go performance to be within the margin of error, with different phases favoring each.

Debate: Why Not C#?

  • Some argue C# has strong AOT, good memory control, and could match or exceed Go, questioning the “AOT not mature enough” rationale.
  • Others counter that requiring .NET on all platforms (especially Linux CI) is a serious adoption barrier compared to a single Go binary.
  • There is disagreement over how big a deal it is that C# is more class-oriented:
    • One side: you can write function+data-style C# with static classes and extension methods.
    • Other side: that would be non-idiomatic and socially costly for long-term maintenance.
  • Many see the choice as symbolically damaging for C#, reading it as Microsoft “not trusting its own stack”; others call this overreaction and emphasize picking the best tool for TS, not for C#’s brand.

Debate: Why Not Rust?

  • The TS team’s stated concerns: cyclic data structures and custom memory patterns are hard to port directly; Rust would force deeper redesign.
  • Rust advocates in the thread say these problems are solvable with existing crates and that the evaluation likely involved insufficient Rust expertise.
  • Several commenters stress Rust’s higher complexity and slower compile times; Go is praised for very fast builds and low conceptual friction.
  • Some argue Rust would offer a better WebAssembly story; others note WASM is only one of several priorities, and port-friendliness won.

Go vs Other Options & Community Reactions

  • Brief mentions of Crystal, Java+GraalVM, and Java/C# as technically viable but with less mature tooling for this exact use case or worse deployment story.
  • Observers note two loud “camps”:
    • C# users worried about the ecosystem’s future.
    • Rust fans frustrated anything in this space isn’t using Rust.
  • Others welcome the decision as a rare example of a big-company project ignoring “not invented here” and language politics in favor of pragmatic fit.