TypeScript 7

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

El lanzamiento de TypeScript 7, impulsado por un nuevo compilador basado en Go, está recibiendo elogios por aceleraciones drásticas en la verificación de tipos —a menudo alrededor de 8–12x en bases de código grandes—, al tiempo que reabre preguntas sobre la elección del lenguaje, la integración con herramientas y la arquitectura a largo plazo. Los comentaristas debaten si la estrategia de reescritura (un port archivo por archivo para mantener compatibilidad bug por bug) era preferible a un rediseño en Rust o C#, y cómo la falta de una API estable del compilador en 7.0 limitará temporalmente la adopción por parte de frameworks y herramientas de editor. El hilo se amplía hacia una reflexión más general sobre la evolución de los sistemas de tipos, el tipado estático frente al dinámico en equipos reales y cómo un tipado más fuerte se ha vuelto central en los ecosistemas modernos de JavaScript y en los flujos de trabajo de codificación asistida por IA.

Port de Go y mejoras de rendimiento

  • Historia principal: el compilador de TypeScript 7, basado en Go, ofrece enormes aceleraciones en la verificación de tipos (a menudo ~8–12x) con menos memoria, especialmente en bases de código grandes (p. ej., VS Code, Sentry).
  • A muchos les sorprende que hubiera menos quejas en HN sobre la lentitud de tsc que sobre rustc, a pesar de que tsc a menudo se siente peor en la práctica.
  • Algunos sostienen que Rust podría ser marginalmente más rápido que Go, pero las ganancias del port a Go ya son “lo suficientemente buenas”, y una reescritura en Rust tardaría más y sería estructuralmente más difícil (estructuras de datos circulares, borrow checker).
  • Otros destacan las ventajas de Go para desarrollar rápidamente, la evolución estable del rendimiento y una traducción más sencilla 1:1 desde JS/TS.

Arquitectura del compilador, APIs y WASM

  • El port se hizo deliberadamente como una traducción fiel, archivo por archivo y bug por bug, no como un rediseño, para preservar el comportamiento.
  • La falta de una API estable del compilador en 7.0 es un gran punto de dolor; muchas herramientas (frameworks, ESLint, ts-jest, etc.) seguirán ancladas en TS 6 hasta que lleguen 7.1 y APIs posteriores.
  • Los builds de WASM están previstos pero no del todo aclarados; distintos grupos quieren:
    • LSP/Monaco en el navegador
    • API del compilador en el navegador
    • binarios CLI dirigidos a plataformas solo-WASM

Impacto en el ecosistema y herramientas

  • Algunos ya ven grandes mejoras prácticas (comprobaciones rápidas antes de commit, editores más ágiles), mientras que otros “solo” ven aceleraciones de 3–4x, pero aun así están contentos.
  • Entornos como Deno y varias herramientas de build/test necesitan integrar TS7 con cuidado porque se conectan al compilador de formas no triviales.
  • El linting y las herramientas (especialmente ESLint) siguen siendo un cuello de botella para la actualización.

Debate sobre tipado estático

  • Un gran subhilo retoma la discusión entre tipado estático y dinámico:
    • A favor de TS: los tipos son cruciales para la mantenibilidad, el refactorizado, la incorporación de nuevos miembros, el soporte del IDE y los agentes de IA; TS ayudó a normalizar sistemas de tipos sofisticados en el mundo JS.
    • Escépticos/anti-TS: lenguajes dinámicos o con tipado gradual (Python, Ruby, JS + JSDoc/Zod) más pruebas pueden ser suficientes, especialmente para equipos pequeños, prototipos o “vibe coding”.
    • Algunos argumentan que los primeros sistemas de tipos estáticos (estilo Java/C) eran torpes; los modernos, con inferencia, uniones/tipos suma y pattern matching, cambian las compensaciones.
    • Sigue habiendo desacuerdo sobre si los enfoques sin tipos o de tipado dinámico son “serios” para sistemas grandes.

Elecciones de lenguaje y la era de la IA / “agentic”

  • Algunos ven Go como una buena opción para herramientas de IA/agentic; otros sostienen que el tipado estático fuerte (p. ej., TS, Rust) es todavía más valioso cuando el código es generado por máquinas.
  • Hay tensión entre una programación en el nivel de tipos más rica (HKTs, trucos de tipos complejos) y el presupuesto de rendimiento; compiladores más rápidos tientan a los desarrolladores a usar patrones de tipos más costosos.