TypeScript 7

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.