Portar el compilador, el checker y el lsp de TypeScript a Rust, mediante LLM

Artículo original ↗ Discusión en Hacker News ↗

Los ports de TypeScript al Rust impulsados por LLM están generando preguntas sobre coste, rendimiento y mantenibilidad. Los comentaristas debaten la afirmación destacada de “$400k en tokens de API” (en gran parte subvencionados mediante suscripciones), comparan la eficacia de los modelos de OpenAI y Anthropic para esta tarea, y evalúan Rust frente a Go y JavaScript para compiladores, especialmente al apuntar a WebAssembly. Muchos ven el proyecto como una demostración de concepto llamativa —más rápida que la cadena de herramientas oficial, pero probablemente sin mantenimiento— y como una primera pista de un futuro en el que sistemas grandes y complejos se traduzcan rutinariamente entre lenguajes por máquina.

Coste del proyecto y economía de los LLM

  • El “$400k en tokens con precio de API” del README provocó un amplio debate.
  • Varios comentarios señalan que ese es un coste teórico equivalente al de la API; en la práctica se hizo mediante suscripciones y créditos de evaluación, con un gasto real informado de alrededor de ~$24k y posiblemente mucho menos para el pase final exitoso.
  • Algunos sostienen que citar el coste equivalente a la API es una “flexing” engañosa; otros dicen que es útil para indicar cuánto costaría el trabajo a precios de lista.
  • También se discute si las empresas de IA “pierden dinero” con usuarios intensivos de suscripción; algunos apuntan a márgenes brutos reportados altos y argumentan que las suscripciones al menos alcanzan el punto de equilibrio.

Rust vs Go vs JS y WASM

  • Varios comentarios señalan que, en la práctica, esto es un port a Rust de una reescritura en Go del compilador original de TypeScript.
  • Debate sobre Go frente a Rust: Go se eligió por ergonomía y facilidad de portabilidad; se argumenta que Rust es mejor para rendimiento y WebAssembly (binarios más pequeños y rápidos, runtime mínimo).
  • Otros dicen que Go también puede apuntar a WASM (especialmente TinyGo) y que GC frente a no-GC no es una historia simple de “más rápido/lento”.
  • Algunos sostienen que JS nunca se consideró seriamente como el lenguaje de implementación nuevo y que eso fue una oportunidad perdida; otros señalan que TS originalmente estaba en JS.

LLMs como programadores: calidad, pruebas y confianza

  • El port fue producido en gran parte por LLMs, y un modelo (Opus) superó de forma significativa a intentos anteriores de OpenAI en velocidad y progreso.
  • El autor afirma que “nunca leyó una línea de este código”, lo que alarma a algunos comentaristas que lo ven irresponsable; otros sostienen que pasar toda la suite de pruebas de TS es suficiente.
  • Preocupaciones planteadas: huecos ocultos donde las pruebas originales dependían del “sentido común”; mantenibilidad de código que ningún humano entiende; evolución a largo plazo bajo requisitos cambiantes.
  • Contrapunto: en sistemas muy probados, los agentes que iteran contra las pruebas pueden dejar menos huecos que los humanos, y los flujos de trabajo futuros podrían centrarse en añadir pruebas en lugar de editar código manualmente.

Seriedad, impacto y reacciones emocionales

  • Algunos ven el proyecto como un meme/experimento poco probable de mantener, parecido a “hacer correr Doom en un microondas”, pero aun así importante como demostración de capacidad.
  • Otros enfatizan utilidad real: se informan aceleraciones de 1.6–4x sobre tsc en algunos proyectos del mundo real, y una mejor idoneidad para despliegues en WASM.
  • División emocional: algunos sienten que las reescrituras con IA “eliminan el oficio” y hacen que estos proyectos sean menos inspiradores; otros se centran en la explosión de lo que es prácticamente posible cuando el coste de desarrollo cae drásticamente.