Why TypeScript 7.0 Was Rewritten in Go (and what it means for your dev stack)
Over the last year, the team that invented TypeScript ported the TypeScript compiler and tools to Go . Not Rust. Not C++. Go . Microsoft’s numbers show build times improving by roughly an order of magnitude in the Go-based TypeScript 7.0. In the age of AI-assisted development, one of the largest JavaScript/TypeScript organizations on earth chose Go for its flagship tool. Microsoft’s reasons were pragmatic, and Anders Hejlsberg laid them out : the existing compiler’s function-heavy style ported to Go nearly one-to-one, both the old and new compilers depend on garbage collection, and native code with shared-memory concurrency is where the 10x came from. The announcement doesn’t mention AI once. But the properties that made a pragmatic 1:1 port possible: simple functions, no hidden magic, a GC, code a team can hold in its head, are the same properties the next era of development demands, and that’s what this post is about. Go was built on a bet: optimize for the reader, not the writer, in exchange for less code to misread. LLMs read code more than any human ever could, and as they write a growing share of it, humans become even more reader-heavy. Agentic development is the most extreme test yet of the goal Go was built for: readability, maintainability, long-term correctness at scale. The conventional argument for Python and TypeScript in the AI era is strong on the surface. Python has PyTorch, LangChain, and the ML ecosystem. TypeScript has the web and a vast developer pool. LLMs trained on mountains of both write them fluently, confidently, and fast. Python and JavaScript were designed as scripting languages: fast to write, forgiving, dynamic. TypeScript adds structure on top, but it’s a compile-time overlay: types are erased at runtime, so none of TypeScript’s guarantees survive execution. TypeScript hasn’t displaced JavaScript so much as grown alongside it: GitHub’s 2025 Octoverse report has TypeScript overtaking Python and JavaScript by monthly contributors, but JavaScript still generated nearly double the new repositories over the same 12 months, and GitHub’s own summary is blunt: “JavaScript is still massive,” and the combined “JavaScript/TypeScript ecosystem still accounts for more overall activity than Python alone.” Agentic systems aren’t scripts, though; they’re services, pipelines, CLIs, and distributed systems running in production for years, and all three languages fight that design at every step: complexity management, dependency isolation, deployment, runtime safety. Go was designed as a systems language for large, long-lived software, and the industry is converging on exactly that category: compiled, safe, built to run for years, not scripted for an afternoon. The most exciting thing happening in TypeScript right now is its port to Go. The most exciting things happening in the Python world are mostly happening in Rust: Pydantic ’s validation core is Rust, Polars is Rust, HuggingFace tokenizers is Rust, and Astral’s is Rust too. Go’s share of that shift looks different but is just as telling: it’s the default choice for the infrastructure the current wave of agentic tools is built on. Ollama , the standard way to run local models, is Go. Weaviate , the vector database behind countless RAG and agent-memory stacks, is Go. Temporal , the durable-execution engine teams use to orchestrate long-running agent workflows, is Go. Charm’s Crush , a beautiful AI coding agent CLI in the same category as Google’s Antigravity , is Go too. Even GitHub’s own MCP server , the reference implementation for connecting AI agents to GitHub, is Go. In a development loop, the question isn’t “which language is easiest to write?” It’s “which is easiest to write, review, and ship?” Agentic development multiplies that question. A machine now asks it hundreds of times a day. An agentic coding loop looks like this: implement → build → test → analyze failure → self-correct → repeat. A human developer runs this loop maybe a dozen times per hour; an autonomous agent runs it dozens of times per task : what Anthropic’s guidance on coding agents describes as systems that “iterate on solutions using test results as feedback.” That frequency changes the economics of language choice. Wes McKinney named this shift in his essay on agent ergonomics : once an agent is doing the coding, fast compile-test loops, frictionless distribution, and deterministic builds matter more than whether a language is pleasant for humans to type. He didn’t just write about it. Roborev , his continuous background code-review tool for AI coding agents, is built in Go. Go solves four compounding problems that most engineers don’t notice, because they’re so used to the friction they no longer see it. Each one is paid for in the same currency: developer time and focus, agent iterations, and API dollars spent correcting what the language let through. And they stack in order: slow builds waste iterations, broken dependency resolution wastes entire runs, weak error feedback lets mistakes survive those runs, and ecosystem churn invalidates what the agent knew before it started. A several-minute build is routine for large Rust or C++ projects: a minor break for a human, but hours of wasted cycles for an agent running 50 iterations on a feature. Go compiles almost instantly, keeping the loop tight. Python’s still doesn’t guarantee deterministic installs by default, and version conflicts across machines remain common even with virtual environments. Node’s actually handles conflicting transitive dependencies well: nested can hold multiple versions of the same package side by side, and plus make installs far more reproducible than they used to be. Where npm still gets stuck is peer dependencies, where conflicting requirements throw errors that need manual untangling. That version flexibility costs deep, duplicated dependency trees that bloat and inflate the surface area an agent has to reason about. Both ecosystems also let arbitrary code execute at install time ( , scripts), a real supply-chain risk that’s bitten each more than once. Go takes a different approach by default: pins exact checksums, a single version of each module is selected deterministically for the whole build, and there’s no install-time code-execution hook for a compromised dependency to exploit. For an agent generating and deploying continuously, that’s less version drift and a smaller attack surface. Python’s type hints and TypeScript’s type system can catch real mistakes before runtime, when tools like , , or run as part of the loop. But both come with an asterisk: Python’s typing remains optional and unevenly adopted, even as tools like Pydantic push teams toward it, and TypeScript’s guarantees are erased at runtime, with a sanctioned, zero-cost escape hatch whenever code hits friction. That’s the incentive an agent under time and token pressure responds to: reaching for to make something compile costs nothing in the moment, whatever the wider ecosystem’s norms are. Jesse Vincent, who builds the Superpowers agent orchestration framework, has documented what happens when that opt-out exists: agents rationalize their way around rules. In one now-infamous incident , an AI agent in his environment deleted test files to make failing tests disappear: internally consistent logic, since tests that don’t exist can’t fail. His insight, in his own words : “A rule has an opt-out path (I can rationalize ‘I’ll do it after this one thing’). A gate doesn’t — the next action is blocked until the gate condition is met.” Go has no such opt-out. Go does have (it’s the alias for ), but it isn’t TypeScript’s . TypeScript’s turns the checker off for everything it touches; Go’s is still checked at every use site, and the compiler refuses any operation the type can’t support without an explicit assertion it verifies. The escape hatch is itself gated. When a mistake slips through in Python or TypeScript, it tends to surface at runtime, often after the agent has built more work on top of it, and by then it has compound interest in context and API calls spent. In Go, the same error is caught immediately at compile time, before the agent runs anything. The difference shows in the code itself: Python’s ergonomic advantage is a disadvantage here: the more forgiving the language, the more mistakes an agent can make before getting caught, burning context and API calls along the way. The same gap shows up in code review , now that both sides are often AI: a reviewing agent can see what Python or JavaScript code says but not reliably what it does, since metaclasses and prototype chains hide behavior a static read can’t catch. Go closes that gap the same way it closes the authoring gap: a function name means one thing, method dispatch is by name alone, and there’s no hidden control flow to obscure a bug from either side of the review. Go’s types aren’t a layer added on top; they’re the language itself, covering 100% of the code by construction. This may be the largest of the four. Go’s compatibility promise means code written for Go 1.0 in 2012 still compiles and runs correctly today. The language and standard library only add; they essentially never break what already worked. Nothing in the Node ecosystem offers that guarantee. Major frameworks routinely break compatibility with their own prior versions: Svelte 5’s runes are a different reactivity model than Svelte 4, Vue 3 required rewriting Vue 2’s reactivity model from scratch, and React’s evolution from class components to hooks to server components has left multiple incompatible eras of “how React code looks” in active circulation. Ask which Svelte or Vue version a piece of code targets and you’re really asking whether it runs at all. Python isn’t immune; the decade-long Python 2 to 3 migration is its own cautionary tale. But Node’s churn is faster and more constant. That churn is a specific, compounding problem for agents. An agent’s working knowledge of an ecosystem is a snapshot frozen at training time, and in a fast-churning ecosystem that snapshot goes stale, producing code that looks plausible but targets an API surface already reworked or deprecated. In Go, a training snapshot from years ago is still correct today. In practice, that means an agent can rely on what it already knows instead of re-verifying its assumptions on every task. Dave Rensin, Distinguished Engineer at Google, captured the compounding risk while building a 100,000-user internal tool with AI agents : “If we aren’t careful, we aren’t just writing code faster. We are mass-producing our mistakes.” Rensin wasn’t talking about Go specifically; that risk is generic to AI-assisted development in any language. But it’s exactly the risk Go’s structure (static types, explicit imports, no magic) is built-in friction against: bad code is harder to write in the first place. At PayPal, a team shared with me an experience where a custom C++ database was powerful and correct, but the team had stopped growing: every hire spent months learning the codebase, and most engineering capacity went to maintenance. About six months later, with roughly ten engineers, a Go rewrite outperformed the C++ system in production and cost far less to maintain. Go isn’t faster than C++, so what happened? The bottleneck was never the code’s speed. It was the team’s ability to reason about, maintain, and extend it. Realized performance beats theoretical performance, the same trade agentic teams are making today, just compressed into a much shorter cycle. Rust and Go are complementary and typically occupy different use cases and both have a place in agentic development, but Rust is a specialized tool rather than the default. Rust shares a lot of strengths with Go: memory safety, static typing, no hidden runtime magic. Rust’s compiler errors are famously instructive, too: by this post’s own compiler-as-gate logic, an agent gets real value from a detailed borrow-checker message. However, the two languages diverge exactly where agentic development is least forgiving. Compile times run far longer, as the build-time problem above illustrates, and the expressiveness behind Rust’s safety guarantees (lifetimes, trait bounds, the borrow checker) costs the single-obvious-way readability Go guarantees by design. The cost shows up hardest at refactor time: in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust, and refactorability is the property agentic development leans on hardest. An agent, not a human, now does that rework, and agents need far more of it to get code right. The more complex the language, the more likely an agent misreads it and produces a bug that compounds over iterations. Rust’s zero-cost C ABI bindings, via tools like PyO3 and maturin, make it unusually easy to drop a compiled Rust core underneath a Python package, which is why pydantic, Polars, and HuggingFace tokenizers chose it. Go has historically been the weaker fit here, since cgo added real overhead to that kind of embedding. While Go is closing that gap: Go 1.26 cut the baseline overhead of cgo calls by about 30% , Rust remains the better choice for a lot of use cases. For agentic development, though, the tradeoff is clear: Go’s simplicity and readability make it the default choice for the systems layer that agents increasingly run on, while Rust is a specialized tool for when its guarantees are worth the cost. Everything above is a cost multiplied by iteration count. Context is the constant cost of agentic work, and more of it doesn’t mean better. The assumption behind “just use a bigger context window” is that a model reasons over its 200K or 1M tokens uniformly. Chroma’s 2025 study across 18 leading LLMs (GPT-4.1, Claude 4, Gemini 2.5, Qwen3) tested that directly, holding task difficulty constant and varying only input length, and found the assumption false: performance degrades as input grows, even on trivial tasks. The biggest driver is what the researchers call distractors: content topically related to what the model needs but not the answer. One distractor measurably hurts accuracy; four compound the damage. Instead of trying to grow the context window, the far better and more economical approach is to reduce the input. A class hierarchy, a mixin chain, a decorator stack: that’s a field of distractors to an agent tracing a bug. A call resolving through diamond inheritance, a metaclass rewriting behavior at runtime, an override buried three classes up: none of it is the logic the agent needs, but the agent still has to load it, weigh it, and rule it out, inside the same window where its reasoning is already degrading. That’s why agents confidently ship code that ignores an inherited override or calls the wrong mixin’s method. Go’s design is minimal and explicit. What a file needs lives in that file and its direct imports: no inheritance chains, no mixins pulled in from six directories away, no metaclass rewriting method resolution at runtime. A function name means one thing, and the compiler enforces it. The tokens Go code needs are almost entirely relevant tokens. That has a second effect beyond accuracy: it lowers the model a task requires. A bug that fits in 20,000 clean tokens doesn’t need the same frontier reasoning as one buried in 150,000 tokens of framework noise. Simpler, lower-distractor code is easier for a model to get right, which means smaller, cheaper, even local models can write working Go where they’d fail on the Python or Java or Rust or TypeScript/JavaScript equivalent. This matters even more when the AI companies stop subsidizing their costs, which we’ve already seen begin. A language whose code stays simple enough for a modest model to handle correctly has a cost structure that survives that subsidy going away. The same property pays twice: what lets a smaller model write the code correctly is what lets a human reviewer read it quickly, since neither side has anything hidden left to re-derive. Beyond even this, it’s more likely to get the code right the first time, which means fewer iterations, fewer API calls, and less context burned and more time the model can spend on tasks without humans needing to intervene. Context efficiency is the sharpest form of the same bet Go made in 2009: optimize for the reader, human or machine, over the writer. The same reader-first bet shows up at the surface of the code. ships with Go and runs across the community’s code. Every Go file (human-written, machine-generated, decades old, or written by an agent this morning) looks structurally identical. Simon Willison, who has spent considerable time building AI-assisted Go tools, observed this directly : “I’m enjoying how there’s generally one obvious way to do things and the resulting code is boring and readable—and something that LLMs are very competent at writing.” When every Go file looks the same, an agent can be seeded before it starts working. Point it at Go’s standard library ( , , ) and it immediately produces idiomatic, production-quality code, with no guessing about versus or versus . Drop in something like go-skills and the seeding gets more direct still, since the agent now has explicit, reusable guidance on writing idiomatic Go rather than inferring conventions from scattered examples. For code review, human or AI, attention goes entirely to logic instead of formatting noise. Most language comparisons focus on authoring: how fast can you write code? But the software development lifecycle doesn’t end there: build, test, deploy, debug, maintain. In an agentic workflow, every one of those steps runs at machine frequency. Over the past decade, Go’s ecosystem evolved from a language into a complete SDLC platform: fuzzing became built-in, vulnerability management matured with , workspace mode unified monorepo development, and module proxies reduced version conflicts. None of this required reaching outside the Go ecosystem. Dependencies are handled by , deterministic and identical on laptops, CI, and containers, unlike or , where every resolution failure is an iteration lost. Testing needs nothing beyond : no framework decision, no fixtures to configure. Drop a file next to the package, write a -prefixed function, run one command. For an agent enforcing test-driven development, that reliability makes the gate deterministic in a way Python’s fixture sprawl doesn’t. Compilation stays fast thanks to precise dependency graphs, a direct multiplier on iteration throughput. And deployment is just : a single, self-contained binary with zero runtime dependencies, no interpreter versioning, no container startup time. Copy the binary and run it. These advantages don’t add linearly, they compound. Faster loops at every step of the cycle mean more iterations per hour, lower API costs, and more reliable outcomes. The point of this article was never “replace Python” or “replace TypeScript.” Betting everything on a single language for every layer of a stack is the same mistake no matter which language wins. The real question is narrower: for the systems, services, and infrastructure layer that agentic workflows increasingly run on, which language fits best? In 2026, that’s Go more often than not because it fits that layer unusually well. Python’s ML ecosystem (PyTorch, LangChain, Transformers) isn’t going anywhere, and it shouldn’t. For training models and running inference, Python is the answer. Go doesn’t compete there. It complements it. Go can run underneath Python just as easily as beside it. Simon Willison built a tool called that packages compiled Go binaries as Python wheels distributed on PyPI: any Go binary becomes a standard or a one-liner, and his own , a concurrent filesystem scanner written in Go, ships exactly that way. Armin Ronacher, creator of Flask, makes the same point from the other direction: porting MiniJinja from Rust to Go cost him 45 minutes and $60 in API calls, which is why he argues that “the cost of coding is going down dramatically… the breadth of an ecosystem matters less.” Python orchestrates, Go executes underneath, and the lock-in argument for picking only one ecosystem weakens every month porting between them gets cheaper. You don’t have to choose between Go’s structural advantages and Python’s ecosystem; you can have both. Go was designed to lower the total cost of software at scale, exactly the problem agentic development now amplifies to the breaking point, and every property that made Go good for human-sized teams turns out to suit machines running thousands of iterations per day just as well. None of this makes Go the only language worth using. Python still owns the ML ecosystem, and there are real reasons to reach for Rust, TypeScript, or something else for a given task. Rather than “one language to rule them all”, treat Go as your default for the systems, services, and infrastructure layer of agentic development, and require a specific reason to reach for something else. When starting a new service, CLI, or system, ask “why not Go?” If you can name a compelling reason (a critical library that doesn’t exist, a performance profile Go can’t meet, a team investment so deep migration costs exceed savings), make that case. If you can’t, Go is very likely the right default. Every percentage point lost to slower builds, flaky dependencies, or runtime surprises is API cost. As agentic workloads scale through 2026, language choice may be the single biggest lever on that cost. Teams that remove this friction early will iterate cheaper and faster than the teams still paying for it.
Programming
Go
TypeScript
C++
Java
Open Source
AI
Business
Career
Security
Design
Web Development
Cloud
Entertainment
Rust
DevOps
Tutorial