libghostty 1.0: el motor que dibuja millones de terminales ya no se reescribe en cada casa

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Mitchell Hashimoto recién lanzó la versión 1.0 de libghostty, la biblioteca en C de emulación de terminal que sacaron de las entrañas de Ghostty. Y hay un dato que resume de qué va todo esto: hoy los usuarios del motor libghostty superan, por mucho, a los de Ghostty la aplicación. El código que entiende las secuencias de escape de tu terminal se volvió un componente más, como zlib o libcurl, y eso cambia la pega de todos.

El 1.0 no es un número, son promesas

Antes de 1.0 era una API experimental: podías usarla, pero cualquier versión nueva podía romperte la compilación. Ahora hay ABI estable, versionado semántico, símbolos con versión en ELF y CI que verifica cada cambio con libabigail contra una línea base. Cuando Neovim aprobó el PR que reemplaza libvterm por libghostty-vt, los mantenedores esperaron justamente esto: un release etiquetado para que las distribuciones lo empaqueten aparte. De paso, ese PR cierra un issue de 10 años sobre el reflow del scrollback al redimensionar una ventana. Diez años de bug acumulados en el emulador de un editor, resueltos cambiando el motor.

Quiénes están dentro ya

La terminal de los IDE de JetBrains (IntelliJ, PyCharm, GoLand) ahora corre sobre libghostty: son más de 12,5 millones de usuarios activos según el reporte de JetBrains. KDE anda experimentando con Kwi como reemplazo de Konsole. Turborepo la usa para renderizar la salida de tareas en su TUI, OrbStack la integra, y hay un build WASM con API compatible con Xterm.js para correrla en el navegador. Además, una ola de herramientas de agentes de código la adoptó en vez de reescribir su propio emulador: por qué empezar de cero si el trabajo duro ya está hecho.

El test que me impresionó

Hashimoto cuenta que corrió 10.000 terminales activas, cada una con un shell vivo escupiendo output, en un server Linux de 4 cores y 8 GB de RAM. Tuvo que usar dash, porque bash gastaba más memoria que la biblioteca misma. Si has corrido crones y sesiones SSH largas en un VPS de los baratos como yo, te cae el velo: la parte «difícil» de dibujar texto en terminal es barata si nadie reinventa la rueda. La biblioteca no crea threads, acepta un allocator custom y se compila hasta freestanding para bare-metal en RISC-V, con licencia MIT y nada de copyleft en el árbol de dependencias.

Mi lectura

Este patrón me gusta harto. Durante 30 años casi cada emulador (xterm, gnome-terminal, la terminal de cada IDE, cada editor) implementó por su cuenta el intérprete de secuencias de escape, con sus rarezas y sus bugs. Centralizarlo en una biblioteca con ABI congelada, empaquetable por cualquier distro (tarballs firmados, manifiesto de dependencias con SPDX, y funciona en musl) es infraestructura seria, de las que uno agradece cuando mantiene varios servidores.

El lado oscuro, obvio, es el monocultivo. Si aparece el bug de seguridad del año en libghostty-vt, golpea a JetBrains, Neovim, KDE y medio ecosistema a la vez, igual que pasa con libcurl u OpenSSL. Aun así, prefiero ese trade: un motor único, auditado y con ABI estable antes que una zoo de emuladores donde el reflow del scrollback es un bug que vivió una década. El que mantiene software en servidores sabe que lo aburrido y compartido suele ser el camino corto.

Fuente de inspiración: Libghostty 1.0