When the TypeScript team announced they were rewriting the compiler in Go, it was framed as a pragmatic shift driven by performance. Many applauded the decision, including some of my LogRocket author colleagues in their article, TypeScript is Going Go: Why It’s the Pragmatic Choice. But now, with two months of hands-on experience with the Go-powered compiler, it’s time to reflect on the other side of the story: one that’s less about benchmarks and more about the broader developer ecosystem, tooling disruption, and long-term maintainability.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
Let’s start with the obvious: yes, Go is fast. The new compiler is reportedly up to 10× faster in some scenarios. Developers using large codebases in VS Code are seeing faster feedback loops. CI pipelines are shaving seconds to minutes off their runs. These are measurable, valuable wins.
But performance alone doesn’t make a language choice pragmatic.
TypeScript didn’t evolve in isolation. It was born out of and thrives in an ecosystem deeply tied to JavaScript and its tooling. This ecosystem is full of tools like ts-loader, ts-blank-space, custom linters, and AST transformers that depend on long-stable, accessible JavaScript/TypeScript APIs. These tools now face an uncertain future.
Many internal compiler APIs are being rewritten in Go. Some won’t make the cut at all. While the core TypeScript CLI and language services will continue to function, any project that deeply integrates with the compiler internals will likely break or require costly rewrites.
Type-checking loaders, custom compilers, and advanced plugin systems are suddenly brittle or obsolete.
This is more than technical debt; it’s ecosystem debt.
If performance were the driver, why not choose Rust? Tools like SWC and Deno have shown Rust’s ability to deliver both speed and safety in the JS ecosystem. And unlike Go, Rust is already the default language for many modern TypeScript-adjacent projects.
Yes, Rust has a steeper learning curve and lacks a garbage collector. But these challenges come with a payoff: control, memory safety, and the ability to write highly modular, embeddable components. In contrast, Go’s simplistic type system and opinionated concurrency model make it great for monolithic systems, not language tooling that thrives on extensibility.
In short: Rust is harder to port to, but easier to build on. Go is easier to port to, but harder to innovate on.
Beyond the ecosystem breakage and missed opportunity to embrace Rust, the decision to port TypeScript to Go introduces long-term tradeoffs that are already becoming apparent:
While Go 1.18 finally introduced generics after years of community requests, its type system remains far less expressive than TypeScript’s.
There’s no concept of higher-kinded types, no type inference as powerful as what TypeScript supports, and constrained interfaces often require verbose boilerplate. For a project that revolves entirely around types — and complex ones at that — this is a fundamental mismatch that could slow down future enhancements or make them harder to implement cleanly.
Building compilers and static analyzers typically requires a strong reflection system, AST-level manipulation, and introspective APIs. Rust and even JavaScript offer more usefulness in this space.
TypeScript has built one of the most active language communities in recent history. Most contributors to the TypeScript compiler understand JavaScript or TypeScript deeply, but Go is an entirely different ecosystem with different idioms, tooling, and mental models.
Moving the core compiler to Go introduces a language barrier, increasing friction for contributors and making onboarding more difficult. This could lead to a smaller pool of maintainers, longer feedback cycles, and fewer community-driven improvements.
The original LogRocket post briefly mentioned this concern: the TypeScript team will now write more Go and less TypeScript. This might sound like a non-issue. After all, the language isn’t changing, right?
But writing the language you build is how many of the best DX decisions are made. It’s how bugs are caught early, friction is felt firsthand, and features are shaped by real use. Moving compiler work away from TypeScript breaks that feedback loop.
Over time, this could widen the gap between how TypeScript is built and how it’s used.
While the Go port brings massive benefits on the CLI side (faster builds, better performance), it comes with long-term maintenance and developer experience risks that the TypeScript team will need to actively mitigate.
Ironically, the very pragmatism that TypeScript was built on is now at risk due to reduced community accessibility.
The TypeScript team has stated that the CLI and language server will retain “close compatibility,” but early signs show that’s a moving target. For instance:
Learn more →transpileModule compatibility is uncertaints-loader likely won’t support type checking mode anymore, a significant loss for webpack usersThese are not minor implementation details. They’re breaking changes at the heart of the TypeScript development workflow.
Unsurprisingly, many in the web development world were disappointed that the TypeScript team chose Go over Rust. There’s a large, if not majority, portion of the community that adores Rust, and in some corners, it feels like there’s a push to have everything rewritten in it.
And to be fair, valid concerns and thoughtful arguments are being raised in these discussions.
For example, Evan You, the creator of Vue.js and now involved in Rust-based tooling, publicly voiced concern about Go’s performance in WebAssembly.
His point is critical: web-based editors, playgrounds, and development tools often need to run the TypeScript compiler inside the browser, which effectively means running it as a WASM module:
If Go-based TypeScript performs poorly in that WASM context, it could significantly limit its usefulness in those browser-contained environments. In fact, in his testing, even simple typechecking tasks in Go-WASM were slower than existing JavaScript-based implementations, a worrying datapoint for those invested in web IDE performance.
So while Go may be the right tool for the server-side CLI and IDE tooling, Rust could’ve had the upper hand in all use cases, including browser-based use cases, if the team had the resources and time to do a full rewrite.
TypeScript’s success has always been about more than performance. It’s been about the ecosystem: DefinitelyTyped, tight IDE integration, predictable APIs, and a vibrant community of contributors and tool authors.
The switch to Go may be a pragmatic move in the short term, but it risks alienating the very developers who built the tools that made TypeScript indispensable in the first place.
If pragmatism is the guiding principle, then perhaps we need to zoom out. Is it truly pragmatic to chase performance at the expense of ecosystem continuity, contributor inclusivity, and long-term extensibility?
The Go compiler for TypeScript is a bold move. It brings real speed gains, and those will benefit many developers. But two months in, it’s clear that the costs are deeper than expected. Go, while easy to work with for a small core team, imposes limitations that TypeScript and its ecosystem will feel for years to come.
If the TypeScript team had chosen Rust, the path might have been steeper up front, but the payoff in safety, performance, and ecosystem alignment would have been stronger and more future-proof.
Go was a pragmatic choice if pragmatism only means “easy to build and fast to run.” But TypeScript has always stood for more than that.
Now, the question is whether the community will accept these trade-offs or start building their compilers in Rust anyway.
A practical walkthrough of building local-first, privacy-preserving AI agents using small language models.
async/await in TypeScriptTypeScript’s async/await lets you write asynchronous code that reads like synchronous code, making it easier to understand, maintain, and reason about.
Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the January 28th issue.
Compare mem0 and Supermemory to learn how modern AI apps manage long-term memory beyond RAG and stateless LLM chats.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
4 Replies to "Why Go wasn’t the right choice for the TypeScript compiler"
Average rust user coping that someone used something other than their favourite language and rationalising their own thoughts with a blog:
You’re missing the point here. Speed was just the headline. From the developers (see https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12476218):
The TypeScript compiler’s move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.
I’m sorry, but this reads like an AI-generated post with surface-level opinions.
It was enough to read only the title of the article to realize that it was written by Rust the fanatic.