Hace poco el equipo de TypeScript anunció que están desarrollando un compilador nativo implementado en Go, un movimiento que promete transformar el rendimiento del lenguaje. Este proyecto, apodado “Corsa”, aborda directamente uno de los mayores desafíos que ha enfrentado TypeScript a la hora de escalar bases de código grandes.
La propuesta detrás de este anuncio
Este nuevo compilador nativo en Go para TypeScript mejorara notablemente el rendimiento del lenguaje. A medida que las bases de código crecen, TypeScript no siempre ha sido bueno a la hora de escalar eficientemente.
Por eso, lo que más me emociona de este cambio es cómo transformará la experiencia de desarrollo en editores como Visual Studio Code. La carga de proyectos, que antes tomaba 9.6 segundos, ahora se reducirá a solo 1.2 segundos, ¡una mejora de 8x! Esto significa que desde el momento en que abrimos el editor hasta que escribimos la primera línea de código, todo será casi instantáneo.
Además, el nuevo compilador nativo ya está mostrando resultados impresionantes: en pruebas preliminares, los tiempos de compilación se han reducido hasta 10 veces en la mayoría de los proyectos. Esto no solo elimina las pequeñas fricciones que interrumpen nuestro flujo de trabajo.
Datos de la tabla tomados desde la página oficial de Microsoft, referencia al final del artículo
¿Por qué Go?
Luego de leer el issue del repositorio en GitHub del proyecto (que les dejaré al final), la elección de Go no parece una casualidad en absoluto. El equipo de TypeScript evaluó minuciosamente múltiples lenguajes y exploró diferentes enfoques antes de tomar su decisión, llegando incluso a considerar implementaciones híbridas donde solo ciertos componentes serían portados.
Una de las razones fundamentales para elegir Go fue la necesidad de mantener una estructura de código y una semántica similar a la implementación actual, lo que impactaria notablemente a la hora de portar cambios entre ambas bases de código. Puedo imaginar el desafío que hubiera representado mantener dos implementaciones simultáneamente con estructuras radicalmente diferentes y porque fue crucial para el equipo de TypeScript mantener ambas bases de codigo durante un buen tiempo en el futuro.
Habiendo experimentado personalmente con Rust en proyectos personales, puedo entender las razone por las qué eligieron Go en lugar de Rust o incluso C# (una pregunta que muchos se han planteado).
Estas alternativas hubieran requerido un replanteamiento total de la estructuración de los datos, la gestión de memoria y otros aspectos fundamentales del lenguaje, complicando enormemente portar y mantener en paralelo ambas bases de codigo.
Otro factor determinante en esta decisión fue la gestión de memoria. Go ofrece un excelente equilibrio, proporcionando buen control sobre la asignación de memoria sin obligar a los desarrolladores a preocuparse constantemente por ella como ocurre en lenguajes de más bajo nivel. Aunque Go utiliza un sistema de garbage collection, esto no impacta significativamente en la eficiencia del código para este caso.
Por ultimo también mencionan que TypeScript realiza mucho procesamiento de árboles con recorridos ascendentes y descendentes que involucran nodos polimórficos, algo que Go maneja muy bien y de forma ergonómica.
Pero no todo son ventajas; para el equipo de TypeScript también existen algunas limitaciones importantes en su decisión. La interoperabilidad entre Go y JavaScript no es tan robusta como en otras alternativas que consideraron, lo que podría complicar ciertos aspectos de integración. Sin embargo, tienen planes para mitigar este problema y están comprometidos a ofrecer una API para JavaScript que sea tanto eficiente como ergonómica.
Una ventaja adicional de esta reimplementación es que les permitirá alejarse del actual modelo de API, donde los usuarios pueden acceder (e incluso modificar) prácticamente cualquier cosa, lo que ha limitado las posibilidades de optimización.
Esta transición hacia un diseño de API más inteligente y controlado, que también considera la interoperabilidad, les permitirá evolucionar el ecosistema mientras entregan estas impresionantes mejoras de rendimiento.
Nodos Polimórficos: En el contexto de compiladores, son estructuras de datos que pueden representar diferentes tipos de elementos sintácticos o semánticos y que requieren ser procesados de manera uniforme a pesar de sus diferencias. Go facilita este tipo de procesamiento gracias a sus interfaces y sistema de tipos.
Calendario de lanzamiento
El plan es tener una vista previa de la implementación nativa para mediados de 2025, con una solución completa de caracteristicas. Mientras tanto, la versión actual seguirá evolucionando en la serie 6.x. Eventualmente, cuando la implementación nativa alcance paridad de características con la version actual, se convertirá en TypeScript 7.0.
Ambas versiones coexistirán por un buen tiempo. El equipo reconoce que algunos proyectos podrán migrar rápidamente a TypeScript 7, mientras que otros dependerán de APIs específicas o configuraciones heredadas que requerirán seguir usando la versión 6.x por más tiempo.
Impacto directo en el rendimiento y la experiencia del desarrollador
Reducción del tiempo de compilación: Las esperas se reducirán hasta 10x, permitiendo flujos de trabajo más ágiles y ciclos de desarrollo más rápidos.
Menos consumo de memoria: Reducción aproximada del 50% en uso de memoria.
TypeScript finalmente se alineará con el Language Server Protocol (LSP), lo que mejorará la velocidad de herramientas como autocompletado, “ir a la definición” y referencias en editores como Visual Studio Code.