Port do compilador, checker e lsp de TypeScript para Rust, por LLM
Portes do compilador e do verificador de tipos de TypeScript, conduzidos por LLM, estão levantando questões sobre custo, desempenho e manutenção. Comentadores debatem a alegação principal de “$400k em tokens de API” (em grande parte subsidiados por assinaturas), comparam a eficácia dos modelos da OpenAI e da Anthropic nessa tarefa e contrapõem Rust a Go e JavaScript para compiladores, especialmente ao mirar WebAssembly. Muitos veem o projeto como uma prova de conceito marcante — mais rápido que a ferramenta oficial, mas provavelmente sem manutenção — e como um vislumbre inicial de um futuro em que sistemas grandes e complexos são rotineiramente traduzidos entre linguagens por máquinas.
Custo do Projeto e Economia de LLMs
- O “$400k em tokens com preço de API” no README gerou um debate extenso.
- Vários comentários observam que esse é um custo teórico equivalente ao da API; na prática, isso foi feito via assinaturas e créditos de avaliação, com gasto real relatado em torno de ~$24k e possivelmente bem menos para a passagem final bem-sucedida.
- Alguns argumentam que citar o custo equivalente à API é uma “ostentação” enganosa; outros dizem que isso é útil para sinalizar quanto o trabalho custaria a preços de tabela.
- Há discussão sobre se empresas de IA “perdem dinheiro” com usuários pesados de assinaturas; alguns apontam para margens brutas reportadas altas e argumentam que as assinaturas ao menos empatam.
Rust vs Go vs JS e WASM
- Vários comentários observam que, na prática, isto é um port em Rust de uma reescrita em Go do compilador TypeScript original.
- Debate sobre Go vs Rust: Go foi escolhido por ergonomia e facilidade de portabilidade; argumenta-se que Rust é melhor para desempenho e WebAssembly (binários menores e mais rápidos, runtime mínimo).
- Outros dizem que Go também pode mirar WASM (especialmente TinyGo) e que GC vs sem GC não é uma história simples de “mais rápido/mais lento”.
- Alguns argumentam que JS nunca foi seriamente considerado como a nova linguagem de implementação e que isso foi uma oportunidade perdida; outros apontam que TS foi originalmente em JS.
LLMs como Programadores: Qualidade, Testes e Confiança
- O port foi produzido em grande parte por LLMs, com um modelo (Opus) superando significativamente tentativas anteriores da OpenAI em velocidade e progresso.
- O autor afirma que “nunca leu uma linha deste código”, o que alarma alguns comentaristas que veem isso como irresponsável; outros alegam que passar pela suíte completa de testes do TS é suficiente.
- Preocupações levantadas: lacunas ocultas onde os testes originais dependiam de “bom senso”; manutenção de código que nenhum humano entende; evolução de longo prazo sob requisitos em mudança.
- Contraponto: para sistemas amplamente testados, agentes iterando contra testes podem deixar menos lacunas do que humanos, e fluxos futuros podem se centrar em adicionar testes em vez de editar código manualmente.
Seriedade, Impacto e Reações Emocionais
- Alguns veem o projeto como um meme/experimento improvável de ser mantido, semelhante a “rodar Doom em um micro-ondas”, mas ainda importante como demonstração de capacidade.
- Outros destacam utilidade real: ganhos relatados de velocidade de 1,6 a 4x sobre o tsc em alguns projetos do mundo real, e melhor adequação para implantações em WASM.
- Divisão emocional: alguns sentem que reescritas com IA “removem o ofício” e tornam esses projetos menos inspiradores; outros focam na explosão do que é praticamente possível quando o custo de desenvolvimento cai drasticamente.