Um projeto no GitHub chamado ts-rust tem circulado entre desenvolvedores nos últimos dias. Ele migra para Rust, por completo, o compilador do TypeScript que a Microsoft reescreveu em Go, junto com o verificador de tipos e o servidor de linguagem (LSP); a ferramenta de linha de comando se chama tsc-rs. O mantenedor, pingdotgg, é direto na descrição do projeto: todo o código de implementação foi gerado por um modelo de linguagem, e ele mesmo não leu uma única linha.
O projeto está fixado em uma versão upstream do microsoft/typescript-go, correspondente ao TypeScript 7.1.0-dev. Segundo a documentação, os 181.711 testes migrados da versão em Go passaram todos, e nos projetos reais que o autor testou a compatibilidade chegou a 100%. O repositório usa licença MIT, mas mantém os avisos Apache-2.0 do TypeScript e BSD-3-Clause da biblioteca padrão do Go, e tem atualmente mais de 600 estrelas.
Dois caminhos com modelos diferentes
O autor primeiro testou com o GPT-5.6 Sol e o GPT-6 Astra, da OpenAI: o custo de API passou de 400 mil dólares, gerando cerca de 1,3 milhão de linhas de Rust, mas a compatibilidade ficou travada em 84%. Depois ele trocou para o Claude Opus 5.5 e recomeçou do zero: em 10 horas já tinha uma v0 funcional, e o custo total em duas semanas foi de cerca de 24.047 dólares.
"I've never read a line of this code."
(Eu nunca li uma linha desse código.)
No quesito desempenho, o autor usou seu próprio projeto T3 Code como referência: o tsc-rs conclui a verificação de tipos em 7,25 segundos, contra 16,10 segundos do tsc 7 em Go — 2,22 vezes mais rápido. Tomando o tsc 6 em JavaScript como base, o tsc 7 é 7,1 vezes mais rápido e o tsc-rs, 11,4 vezes. Esses números vêm todos de testes do próprio autor, ainda sem reprodução independente, e nem a OpenAI nem a Anthropic se manifestaram publicamente sobre essa comparação.
Comparando com projetos parecidos
Usar modelos de linguagem para migrações de código em larga escala já teve alguns casos públicos este ano. O GitHub já revelou ter usado o Copilot para reescrever um de seus runtimes em 830 mil linhas de Rust; a Mistral usou um agente para migrar 40 mil linhas de Fortran 77 para C++. O ponto em comum desses projetos é ter um conjunto de testes já existente e com boa cobertura funcionando como árbitro.
O ts-rust segue o mesmo caminho. A própria portabilidade da Microsoft para Go foi, em essência, uma reescrita arquivo por arquivo quase “copiada”, e os casos de teste foram levados junto, dando ao modelo um objetivo quase totalmente determinístico: dezenas de milhares de testes, passou é passou. Em tarefas com objetivo claro e retorno imediato como essa, a diferença entre os dois modelos fica bastante ampliada. Já em código de negócio com requisitos vagos e sem rede de testes, não dá para dizer se essa comparação se sustenta.
Limitações já conhecidas
A documentação lista quatro limitações: em monorepos onde o mesmo arquivo pode ser acessado por vários caminhos, o número de arquivos gerados pode ser maior que no tsc; em builds incrementais com tsc -b, é possível ler artefatos antigos ou ausentes; em sessões de edição longas, o consumo de memória cresce lentamente, cerca de 20MB a cada mil edições; o número de versão exibido é o 7.1.0-dev da época da migração, não a versão do npm.
O autor posiciona o projeto como uma versão inicial. Para equipes que querem experimentar, o caminho mais seguro é rodar o tsc-rs em paralelo com o tsc oficial na CI e comparar as saídas de diagnóstico; já usá-lo diretamente para substituir a cadeia de build de produção, sem ninguém ter revisado o código, é um risco que cada equipe precisa avaliar por conta própria.
Fontes: documentação do projeto ts-rust, CocoLoop, discussão no Hacker News; a documentação do projeto foi conferida quanto ao número de testes, custo de API e o tempo e fator do benchmark do T3 Code.