The CI log said 77.8s for the type check, and nobody on the team even looked up anymore. That number belongs to VS Code's 1.5 million lines under the old JavaScript compiler, and with TypeScript 7.0, the native port Microsoft began in March 2025 as Project Corsa, the same job finishes in 7.5s. I've read a dozen hot takes about why the team picked Go over Rust. Here's my position, and it's slightly contrarian: the language debate is the least interesting thing in this release, and the part PHP developers should study is the fine print about what didn't ship.

Credit first, because it's earned. The reasoning for Go was refreshingly unglamorous. The team wanted a port that behaves identically to the old compiler, quirks included, so they translated the existing code file by file rather than redesigning it. A compiler is a thicket of nodes holding pointers to parents, children and declarations, and a garbage-collected language with plain pointers lets that graph survive the move intact. Add shared-memory parallelism for parsing and checking, which a single Node thread never offered, and you get the reported 8x to 12x range on big projects. TypeORM saw 13.5x. date-fns, at 104K lines, got 9.5x. Those are real hours handed back to real people.

Now the fine print. TypeScript 7.0 has no stable programmatic API; that is slated for 7.1. Until then anything that talks to the compiler directly stays on TypeScript 6, and that list includes typescript-eslint plus the template tooling for Vue, Svelte, Astro, MDX and Angular. Deprecations also became hard errors and strict mode is on by default. So a large slice of the ecosystem gets to watch the speedup from the other side of the glass.

This is where I start thinking about our own house. PHP static analysis is written in PHP, and its value has never been the core engine alone. It's the extension layer: the framework-aware plugins that teach an analyser what a facade returns, what a repository method hydrates, which magic property is actually real. Half the PHP shops I know would not run static analysis at all without those plugins, because the raw findings on a framework codebase are mostly noise. Whenever someone floats a native rewrite of our analysers, and someone always does, the benchmark slide gets the applause while the plugin API is the thing that decides whether anybody can actually switch.

The strongest counter-argument deserves a fair hearing. Speed changes behaviour. When a full analysis takes ninety seconds people run it in CI and nowhere else; when it takes nine they run it on save, and the bugs it catches move from the pull request to the editor, which is worth more than any plugin. You could argue Microsoft made the right call shipping the fast core first and letting integrations catch up, since waiting for everything would have delayed the win for the majority who just run tsc. I think that's correct for TypeScript, with Microsoft's staffing and a 7.1 already on the calendar. I'm far less sure it transfers to an ecosystem like ours, where the analysers are maintained by a handful of people and the plugins by a scattered crowd of volunteers who can't absorb a breaking API on someone else's schedule.

So if I were advising a PHP tool author tempted by the native route, I'd turn the TypeScript order around. Define and freeze the extension contract first, in the current implementation, and only then swap the engine underneath it. The faithful-port approach the TypeScript team used actually supports this: if the new code mirrors the old structure line for line, the boundary that plugins touch can mirror it too. And keep in mind how much PHP itself has already given us for free. A lot of the gains that once required leaving the language now come from the engine getting faster and from running work in parallel processes, which our analysers already do.

None of this makes me less impressed by the numbers. Watching a minute-long check shrink to the time it takes to switch tabs is a thrill, and I'll admit I timed a TypeScript project at work out of pure curiosity. But a tool is only as fast as the slowest piece of your actual workflow, and if your lint step is pinned to version 6, the clock on your CI hasn't moved much.

So here's what I'd love to hear from you, especially if you maintain or lean heavily on analyser plugins: if a native rewrite of your PHP static analyser promised a tenfold speedup but left your framework extensions broken for six months, would you switch on day one, or wait for the API?