TypeScript em Rust: o rewrite de US$ 420 mil

Existe hoje um rewrite completo do TypeScript em Rust, chamado TSC RS. Ele foi construído por agentes de IA em duas semanas de trabalho efetivo, custou cerca de US$ 20 mil em inferência de API e roda aproximadamente 2x mais rápido que o TSGO, o port oficial da Microsoft em Go.

O que é o TSC RS, o TypeScript em Rust

O TSC RS é um rewrite completo do compilador, do verificador de tipos e do LSP do TypeScript em Rust, anunciado em outubro de 2026 por Theo, criador do canal t3.gg. O projeto não saiu do zero: agentes de IA portaram linha por linha o typescript-go, o TSGO oficial da Microsoft, e depois otimizaram o resultado.

O autor afirma que não leu uma única linha do código gerado. O objetivo original não era criar um produto, e sim um campo de testes para medir até onde os modelos de IA conseguem ir em tarefas consideradas impossíveis. Mesmo assim, o projeto virou um pacote utilizável, com compatibilidade declarada de 100% como substituto direto do TSGO e do TSC 7, segundo o próprio autor. O compilador oficial continua sendo mantido no repositório microsoft/TypeScript.

Vale separar as entidades aqui. O algoritmo e a linguagem são da Microsoft; o TSGO é o port oficial em Go; o TSC RS é um projeto independente de Theo. Os números de performance do TSC RS pertencem ao projeto independente, não ao time do TypeScript.

Quanto custou de verdade o rewrite

O headline de US$ 420 mil esconde uma conta bem diferente. Theo reporta ter queimado US$ 400 mil em tokens do CodeEx da OpenAI sem chegar a um resultado viável, e depois US$ 20 mil em inferência do Opus 5.5, da Anthropic, que concluiu o port em duas semanas.

Como ele usou assinaturas do Claude Code em vez de API direta, o custo efetivo estimado ficou em torno de US$ 500 de utilização de assinatura — cerca de dez limites semanais de uma conta, ou dois meses e meio de uso. Todos esses números são relatos do próprio autor, medidos sobre os logs dele, e não uma medição independente.

A lição prática é sobre o caminho, não só o preço. Os modelos OpenAI tentaram o port direto de JavaScript para Rust e atingiram cerca de 84% de compatibilidade antes de travar. O Opus partiu do código Go da Microsoft, que já era uma tradução fiel do TypeScript, e só então portou para Rust. A mesma tarefa muda de impossível para viável quando o ponto de partida muda.

Por que o compilador do TypeScript é um problema difícil

Transformar TypeScript em JavaScript é a parte fácil. Remover as anotações de tipo e emitir JS válido é tão trivial que já existem várias ferramentas fazendo isso há anos. O gargalo sempre foi o type checking: garantir que os tipos estão corretos em todo o projeto, o que é muito mais lento e complexo.

Foi por isso que times de bases de código grandes separaram transpilação e verificação em caminhos distintos. Theo conta a experiência dele no Twitch: o comando de dev demorava 2 minutos para iniciar, e cada salvamento levava de 30 segundos a 1 minuto para aparecer no navegador. Separar os caminhos derrubou o ciclo para menos de 5 segundos.

O esbuild, criado por Evan Wallace quando era CTO da Figma, levou essa separação adiante escrita em Go: bundling rápido de TS, CSS e assets para o navegador. Mas o esbuild não verifica tipos. E o sistema de tipos do TypeScript é Turing-completo — já portaram Doom inteiro para dentro dele —, então reproduzir o verificador em outra linguagem exige codificar fielmente todas as excentricidades do JavaScript, como prototipagem e mutação de tipos em tempo de execução.

Por que a Microsoft escolheu Go em vez de Rust

A Microsoft escolheu Go para o port oficial do compilador porque queria concorrência nativa para aproveitar todos os núcleos da máquina, e Go entrega isso com uma sintaxe parecida com JavaScript. Theo defende a escolha, embora se declare um crítico confesso da linguagem: em fevereiro de 2024, ele já havia tuitado que Go era a linguagem certa para tooling de build do ecossistema JavaScript.

O argumento central envolve o garbage collector. Em um serviço web que precisa responder em 25 milissegundos, uma pausa de coleta de lixo cria picos de latência ruins. Em um processo longo, como compilar um app grande que leva segundos ou minutos, o custo do GC vira ruído estatístico: uma requisição 10x mais lenta em cada mil não muda o total de forma perceptível.

Go não exige gerenciar memória manualmente como Rust, o que acelera o desenvolvimento do próprio compilador. O trade-off aparece em outro lugar: portar Go para WebAssembly é ruim, porque o binário precisa embutir o runtime de coleta de lixo, ficando grande e lento. Esse detalhe, aparentemente pequeno, é a semente do motivo secreto do projeto.

Performance: o TypeScript em Rust contra TSC 6, TSGO e Bun

O TSC RS, versão do TypeScript reescrita em Rust, compete hoje com três ferramentas: o TSC 6 escrito em TypeScript, o TSGO da Microsoft em Go e o bun check do Bun. Nesta seção você vê os números de velocidade que Theo reportou e o ponto crítico do confronto: a fidelidade dos erros de tipo em projetos reais.

Segundo os números reportados por Theo, o TSC RS é cerca de 12,5x mais rápido que o TSC 6, a última versão do compilador escrita no próprio TypeScript, e cerca de 2x mais rápido que o TSGO. Ele chegou a medir picos de até 20x contra o TSC 6 em tarefas específicas. São medições do autor em projetos reais como o T3 Code, tRPC server, Sentry e Excalidraw, e não um benchmark independente.

O comparativo mais curioso é com o Bun, que lançou o bun check, seu próprio verificador de TypeScript em Rust. Theo admite que o bun check é ainda mais rápido que o TSC RS no geral, mas aponta limites de fidelidade: nos projetos dele, o checker do Bun levantou erros incorretos no Sentry e no tRPC, e não passou na base do Effect.

Ferramenta	Linguagem	Velocidade relatada	Fidelidade de tipos
TSC 6	TypeScript	baseline	referência
TSGO (TSC 7)	Go	~10x vs TSC 6	oficial da Microsoft
TSC RS	Rust	~2x vs TSGO, 12,5x vs TSC 6	relatada como drop-in
bun check	Rust	mais rápido que TSC RS	erros incorretos relatados

Um detalhe do caso: o TSC RS embutiu o plugin de diagnósticos do Effect, biblioteca popular para sistemas concorrentes em TypeScript que abusa tanto do sistema de tipos que mantém um patch próprio. Isso torna o TSC RS mais rápido de ponta a ponta no projeto T3 Code do que rodar o bun check e depois o Effect separadamente, mesmo com o checker do Bun sendo individualmente mais veloz.

O motivo secreto: rodar o TypeScript dentro de um isolate do V8

O projeto não nasceu por causa de performance. A meta de longo prazo é atacar o custo do computador onde o agente roda, um problema que cresce conforme a inferência de IA fica mais barata. Segundo Theo, threads de agente no Cursor rodam hoje em VMs de 32 GB de RAM por thread, e o preço de memória e compute sobe 25% a 30% ao ano, enquanto o da inteligência cai.

A alternativa é a arquitetura do Cloudflare. Em vez de uma VM com sistema operacional por cliente, o código roda em isolates do V8, o mesmo motor JavaScript do Chrome, compartilhando o processo real com outros clientes. Isso é barato porque um isolate não tem kernel, nem sistema de arquivos, nem acesso a código nativo. É justamente o que um agente precisa para compilar e verificar código, e aí mora o problema.

O TSC RS fecha esse buraco. Por ser Rust compilado para WebAssembly, ele roda dentro do isolate, diferente do TSGO, cujo GC de Go torna o caminho WASM inviável na prática. Na demonstração, um agente construiu e verificou um app inteiro dentro de um isolate no Node usando menos de 260 MB de RAM e cerca de 4% de CPU, com o sistema de arquivos da máquina em modo somente leitura. Todo o ciclo de desenvolvimento aconteceu dentro do V8: um bash simulado em JavaScript trabalhava junto com o compilador em WASM.

Se a inferência continuar caindo na taxa relatada — Theo cita queda de 10x em quatro meses para um mesmo nível de pontuação no índice da Artificial Analysis —, o compute do agente passa a ser o gargalo. Nesse cenário, a arquitetura de isolate tende a virar o padrão econômico para experiências de desenvolvimento agênticas. Trata-se de uma tese do autor, baseada em dados de custo de terceiros, e não de um fato consolidado do mercado.

Como os agentes trabalharam na prática

O trabalho do humano nesse projeto se pareceu mais com gestão do que com programação. Os prompts, como o próprio Theo mostra com ironia, foram curtos: definir a meta de no mínimo 2x de velocidade contra o build em Go e deixar os agentes iterarem por duas semanas. O esforço real estava no ambiente.

As decisões de infraestrutura incluíram:

1. Liberar acesso SSH a outras máquinas da frota quando a máquina principal ficava sem memória e o systemd travava.
2. Configurar contagem de jobs do Cargo e estado de script para permitir múltiplos workflows em paralelo.
3. Auditar constantemente bloqueios e modos de falha recorrentes, ajustando o ambiente para os agentes não pisarem uns nos outros.
4. Definir um estado final objetivo — 2x mais rápido — para evitar que o agente declarasse vitória após qualquer melhoria isolada.

Curiosamente, o próprio port foi fiel demais em um ponto: quando o Opus terminou a primeira versão, ela era 2 a 3x mais lenta que o código Go, porque reimplementava goroutines e partes da biblioteca padrão de Go dentro de Rust. Só depois da otimização dirigida é que o projeto passou a frente. Dos seis issues abertos no projeto, cinco eram bugs que já existiam no TSC 7 e foram portados junto — evidência inusitada de compatibilidade.

Limites: vale usar o TSC RS hoje?

Para a maioria dos projetos, não vale usar o TSC RS hoje. O projeto ainda é uma criação de uma pessoa, conduzida por agentes, sem histórico de manutenção. Theo recomenda o Bun para quase tudo porque confia mais na manutenção de longo prazo daquele ecossistema. O TSC RS fica interessante quando você precisa da recriação mais fiel do comportamento do TypeScript, algo importante em bases grandes com tipos exóticos.

Os números de compatibilidade e velocidade vêm do autor do projeto. Nenhum benchmark independente confirmou o 2x contra o TSGO ou a compatibilidade de 100% até a data deste artigo. Se você depende do compilador em produção, teste no seu código antes de trocar qualquer pipeline. E acompanhe o TSGO oficial, que segue como o caminho suportado pela Microsoft.

No fim, a história mais útil do projeto não é a velocidade. É a prova de que um port considerado impossível na comunidade virou realidade em duas semanas quando o ponto de partida estava certo. O gargalo da engenharia está migrando de escrever código para desenhar ambientes onde agentes conseguem trabalhar.

Se você também carrega ideias grandes presas em vídeos, como aquelas explicações de arquitetura, benchmarks e decisões que só ficam claras falando, vale transformar esse material em texto. No Skala Blog, você cola a URL de um vídeo do YouTube, obtém a transcrição e gera um artigo estruturado, pronto para revisão. O mesmo raciocínio que levou Theo a documentar o rewrite em vídeo pode virar o artigo técnico que alguém vai encontrar amanhã buscando pelo assunto.

Perguntas frequentes

• O TSC RS substitui o compilador oficial do TypeScript? É um substituto direto declarado pelo autor, com compatibilidade reportada de 100% com o TSC 7 e o TSGO. Não há validação independente publicada, e o próprio criador recomenda o Bun para a maioria dos casos por causa da manutenção.
• Quanto custou o TypeScript em Rust? O número de headline é US$ 420 mil em tokens: US$ 400 mil desperdiçados com modelos OpenAI e US$ 20 mil em inferência do Opus 5.5. Com assinaturas do Claude Code, o custo efetivo estimado ficou perto de US$ 500.
• Por que a Microsoft usou Go e não Rust no TSGO? Go oferece concorrência nativa, sintaxe próxima ao JavaScript e coleta de lixo, cuja pausa é irrelevante em compilações de segundos ou minutos. O trade-off é a dificuldade de rodar Go em WebAssembly.
• O bun check é mais rápido que o TSC RS? Sim, segundo o relato do próprio Theo, o checker do Bun é mais rápido no geral. Porém, ele levantou erros incorretos em bases como Sentry e tRPC, então a fidelidade de tipos é menor.
• Por que compilar o TypeScript para WebAssembly importa? WASM permite rodar o compilador dentro de isolates do V8, como Workers do Cloudflare, onde agentes podem construir apps sem VMs caras. Rust compila bem para WASM; Go, por causa do garbage collector, não.

Source video