Why TypeScript Is Still My Major Language

A while back I was talking with a developer at another company, and they suggested I drop TypeScript and move to Go or Rust. They had three reasons. It's slow and heavy. It's a scripting language at the end of the day. And in the age of AI, it's finished.

I agree with a good part of that. I've used Go and Rust, and I still reach for them when I need to. I just have no plans to promote either one to my major language.

I had been watching esbuild and swc since my days at SalesBoost. Today, bundlers written in Go and Rust ship with the frameworks by default. Back then it was the age of webpack. There was no official support, and nobody around to tell me whether these things were safe to use, so I went to GitHub and read the code myself, weighing how stable it was and whether it fit. After watching for a long while, I wired them into a production product at TainAI.

What I was looking at wasn't bugs. Early projects are unstable, and that's what time fixes. What I really wanted to know was the structure. Whether the code was built to grow, or more precisely, whether the author was going to get eaten by their own codebase.

Open source projects stalled the same way back then. Features piled on until the day a real refactor was needed, and that's where the original contributor let go. The repository stays up, issues go unanswered, and the last commit sits there six months old. So before the feature list, I looked at whether the code was in a shape that could keep going.

I looked for the same thing when picking a monorepo stack. I went through Nx, Lerna, and pnpm workspaces before settling on Turborepo. It was fast and the config was simple. The DX was good. One more thing was that it sat inside Vercel's orbit. Around that time the Next.js issue tracker kept filling with complaints about slow builds. Projects would grow a little and build times became unmanageable, and I didn't think Vercel would leave that alone. It was fairly clear where they would be putting their effort.

So here is what my setup looks like now. The Turborepo that builds this blog was rewritten in Rust. Biome, which I use as formatter and linter, is Rust. Turbopack, now the default bundler in Next.js 16, is Rust too. Open my package.json and most of my build pipeline is already running on Rust.

Last month, TypeScript changed as well. The 7.0 compiler was rewritten in Go and shipped on July 8th, running eight to twelve times faster on full builds. (I can't use 7 yet. There is no stable programmatic API, so the surrounding tools have to wait for 7.1.) Around the time advice arrived telling me to leave the language because it was slow, the language was already solving that in Go.

That is also why I haven't changed my major. I'm not picking one language and staying there. I use what fits each spot.

I build something in Flutter every time a major update lands. I try whatever is new in Swift after WWDC. I wrote Java because a friend who streams needed a Minecraft mod. Go, Rust, and Kotlin come out when there is a spot for them. But only when there is one.

The parts that need to run fast moved to Rust and Go long ago. What I write in TypeScript is the shape of the product, sitting on the pipeline those tools laid down.

At a startup, how fast you can get a POC or an MVP out the door matters, and TypeScript is still strong in that stretch. I also agree that past a certain architectural scale, you should move to Go or Rust.

"It's finished in the age of AI" has a point too. AI has all but erased the cost of learning a new language. Once there is no reason to stick with what you already know, the choice comes down to performance, and native comes first. I see that direction as well.

This conversation is happening in a lot of places right now. There was a piece called If AI Writes Your Code, Why Use Python? and a long Hacker News thread under it. The article argued that the hard languages got easy first, so go to Rust. Reading the thread, though, what landed closest to my own thinking was something else. The real question isn't which language is best. It's that the criterion for picking one is shifting from how fast you can write it to how easily you can verify it.

When you hand code to an agent, it piles up far faster than a person can read and confirm it. What catches the wrong thing there isn't review, it's the type checker. Types are an enormous advantage for AI. And measured by how easily you can verify it, TypeScript holds its own. It has types, and it sits on a mountain of open source, which makes it one of the languages AI has read the most. Give the same instruction in a language with thin training data and the result is different.

Someone in that thread put it this way: "I have written it for 10+ years, know how to debug it and I can smell it within 10 seconds of the agent writing code if it does something that is going to end in a huge foot gun... If I did this with Go or Rust, then it would feel more like 'vibecoding' than AI assisted programming." Knowing a language isn't about comfort. It's about being able to spot what's wrong.

Back to getting eaten by your own codebase. The kind of large refactor people used to abandon because they couldn't carry it can be broken into pieces and handed off now. What makes that safe is, again, types.

So I'm not still on TypeScript. I'm holding the language to the same standard I used when deciding whether to put a young tool into production. TypeScript isn't sitting still either, and rewriting its compiler in Go is the proof.

The next answer doesn't have to be Go or Rust. Zerolang, an experiment out of Vercel Labs, is a language built for agents. The source of truth isn't text a person reads but a graph the compiler has checked, and agents can only push edits that pass. People read the graph projected back into text. It is still experimental, but it shows what "the criterion is moving toward verification" actually means more plainly than anything else I've seen.

When that standard gives me a different answer, I'll move then.