Desde 2012, quando Anders Hejlsberg apresentou o TypeScript ao mundo, o compilador rodou sobre Node.js. Era uma escolha natural na época: a linguagem existe para desenvolvedores JavaScript, e o runtime JavaScript era a plataforma mais acessível para o time. Durante anos funcionou bem. Depois os codebases cresceram.
Em projetos com 100 mil linhas de código, um tsc --watch já demora o suficiente para o desenvolvedor perder o fio do raciocínio. Em monorepos com um milhão de linhas, o problema passa de incômodo para bloqueador: a build do VS Code levava 77,8 segundos no compilador JavaScript. Isso não é sustentável.
Em 11 de março de 2025, o próprio Hejlsberg anunciou o projeto que o time vinha desenvolvendo: uma reimplementação nativa do compilador TypeScript, escrita em Go.
O que é o native port do TypeScript
O repositório microsoft/typescript-go, com mais de 24 mil stars no GitHub, é uma reescrita quase literal do compilador, traduzida de JavaScript para Go. A ideia não é criar um compilador novo com comportamento diferente. É produzir um binário nativo que gera exatamente os mesmos resultados que o compilador atual, só que muito mais rápido.
O pacote já está disponível para testes como @typescript/native-preview no npm, e o binário de linha de comando se chama tsgo — um substituto direto do tsc. A interface é a mesma; o que muda é o que acontece por baixo.
A compatibilidade com TypeScript existente é total. Interfaces, tipos, generics, decorators, a sintaxe JSX: nada muda para quem escreve código TypeScript. O compilador é o motor; o código que você escreve é o combustível. Só o motor foi trocado.
Por que Go e não Rust ou C#
A escolha causou debate. Rust seria o candidato óbvio para muita gente: performance similar ao C, sem GC, ecossistema de tooling em ascensão. C# também teria lógica, sendo a linguagem principal da Microsoft com infraestrutura madura para compiladores.
O time escolheu Go por razões práticas.
Compiladores têm padrões de alocação de memória que se encaixam bem com garbage collector: muitos objetos pequenos de vida curta durante o parsing, seguidos de estruturas maiores que duram o tempo da compilação. Forçar controle manual de memória via Rust tornaria a tradução do codebase muito mais trabalhosa sem ganho proporcional — o compilador não é um servidor que precisa de latências de microssegundos.
A estrutura do código Go também é semanticamente próxima do JavaScript que o compilador TypeScript usa hoje. O time não reescreveu do zero. Traduziu. A similaridade entre Go e o estilo do codebase existente (passagem de valores, estruturas de dados, iterações explícitas) permitiu uma tradução mais direta, com menos risco de introduzir bugs por mudança de semântica.
Outro fator: Go compila para um binário nativo sem dependências externas. O tsgo não precisa do Node.js instalado. Isso resolve um problema real de distribuição: hoje, instalar o TypeScript significa ter o Node.js na máquina.
C# ficou fora principalmente por isolamento: adicionar uma dependência .NET a uma ferramenta do ecossistema JavaScript criaria atrito desnecessário, especialmente em ambientes Linux e Docker onde .NET não é a norma.
Os números que importam
O anúncio de março de 2025 trouxe benchmarks de codebases reais, divulgados pela Microsoft:
- VS Code (1,5 milhão de linhas): de 77,8s para 7,5s (10,4x mais rápido)
- Playwright (356 mil linhas): de 11,1s para 1,1s (10,1x mais rápido)
- TypeORM (270 mil linhas): de 17,5s para 1,3s (13,5x mais rápido)
- date-fns (104 mil linhas): de 6,5s para 0,7s (9,5x mais rápido)
O carregamento do projeto VS Code no editor cai de 9,6 segundos para 1,2 segundo. O consumo de memória é reduzido pela metade.
Para projetos pequenos a médios, o ganho absoluto é menos dramático. Uma build que leva 3 segundos vai para menos de 1 segundo. Ainda é uma melhora real, mas não é o que vai transformar o dia de um dev num codebase de 20 mil linhas.
Onde a diferença é genuinamente transformadora: monorepos grandes, pipelines de CI com dezenas de projetos TypeScript, e a experiência de editor em codebases extensas. Autocomplete mais rápido, verificação de tipos mais ágil, goto definition sem delay perceptível. Eu sinceramente subestimei quanto desses milissegundos acumulam. Até sentar com o tsgo num projeto maior e notar a diferença no editor.
O que muda na sua toolchain
Nada muda no código TypeScript em si. Não há novos erros de compilação, não há tipos quebrados, não há necessidade de atualizar o tsconfig.json. O que muda é operacional.
O tsgo atualmente implementa type-checking e geração de diagnósticos, o coração do compilador. A emissão de código JavaScript (geração dos arquivos .js a partir dos .ts) ainda está em desenvolvimento. Para a maioria dos projetos modernos que usa bundlers como Vite, esbuild ou Turbopack, isso não é problema: esses bundlers fazem a transpilação de TS para JS e usam o compilador TypeScript apenas para checagem de tipos.
Vale notar que o preview atual não suporta --declaration emit, project references (--build) nem integrações de tooling como linters e formatters baseados na TS Language Service API. O uso recomendado por enquanto é exclusivamente --noEmit para checagem de tipos.
O @typescript/native-preview já pode ser testado:
npm install @typescript/native-preview
npx tsgo --versionPara checar tipos sem emitir arquivos:
npx tsgo --noEmitA interface de linha de comando é compatível com tsc. Scripts de CI que rodam tsc --noEmit podem trocar o binário com mínima alteração.
Uma mudança importante está planejada para o language server: o time vai migrar para o protocolo LSP padrão. O servidor atual (tsserver) usa um protocolo proprietário. Com a migração, editores como VS Code, Neovim e outros que suportam LSP ganham autocomplete e type-checking mais rápidos automaticamente, sem mudanças de configuração.
A linha do tempo: TypeScript 6 e 7
O TypeScript 5.x continua com lançamentos regulares em JavaScript. O TypeScript 6.x, ainda em JavaScript, recebe novas funcionalidades enquanto o compilador nativo amadurece, e vai deprecar gradualmente padrões que o native port não precisará suportar.
O TypeScript 7.0 é o alvo final: o tsc oficial passará a ser o binário Go. O TypeScript 6 continuará mantido enquanto a adoção da versão 7 cresce, sem um cliff de migração abrupto.
O repositório typescript-go está listado como staging, com intenção declarada de fazer merge no repositório principal microsoft/TypeScript quando o compilador atingir maturidade suficiente. O estágio atual foca em paridade de features com o TypeScript 6.0.
Conclusão
O que a Microsoft fez não é glamoroso no sentido de adicionar features. É a resolução de um problema de engenharia real: um compilador escrito em JavaScript para verificar código JavaScript inevitavelmente atinge limites quando os projetos crescem o suficiente. A solução foi trocar o runtime por algo que roda mais perto do metal.
O debate sobre Go vs Rust vs C# existiu, e a resposta foi pragmática, o mesmo espírito do TypeScript desde o início. A linguagem que melhor serve a tradução, ao ecossistema de destino e ao perfil de memória do problema.
Para quem trabalha em projetos pequenos, a diferença vai ser perceptível mas não urgente. Para quem vive com CI demorando minutos por causa de type-checking, ou com editor travando em monorepos grandes, este é o conjunto de mudanças mais impactante no tooling TypeScript em anos.
Vale pelo menos um tsgo --noEmit no seu projeto agora para ter uma referência de onde está, e notar a diferença quando o TypeScript 7 chegar.