Show HN: Shitty – terminal rápido. Inseguro en memoria y más rápido que el tuyo

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

Un nuevo emulador de terminal de código abierto llamado “shitty” afirma un rendimiento de renderizado de texto sustancialmente superior al de herramientas populares como Ghostty, Kitty y GNOME Terminal, lo que provoca un debate sobre si esas mejoras de rendimiento importan en el uso cotidiano. Los comentaristas contrastan el rendimiento bruto con factores más visibles para el usuario, como el tiempo de arranque, el comportamiento al redimensionar y la latencia de pulsación, y muchos señalan que rara vez perciben los terminales como un cuello de botella. El nombre provocador del proyecto, el uso intensivo de código generado por IA y el plan de pasar de una base de código basada en GPL a una licencia MIT suscitan argumentos más amplios sobre profesionalidad, ética de licencias y mantenibilidad a largo plazo.

Reclamaciones del proyecto y rendimiento

  • Nuevo emulador de terminal multiplataforma centrado en el máximo rendimiento y escrito en C++ (explícitamente “inseguro en memoria”, es decir, no Rust).
  • Los benchmarks muestran un rendimiento ASCII significativamente mayor que el de terminales populares (Ghostty, kitty, alacritty, GNOME Terminal, etc.).
  • Usa un nombre binario de dos letras st, que se solapa con un terminal existente y plantea preocupaciones por colisiones.

Valor práctico frente a la sobreoptimización

  • Muchos comentaristas dicen que rara vez sienten que el rendimiento del terminal sea un límite y que prefieren funciones, integración y estabilidad.
  • Varios sostienen que el ahorro de tiempo de vida útil por un mayor rendimiento es minúsculo en comparación con el coste de cambiar de terminal.
  • Otros señalan que cargas de trabajo con salidas extremadamente verbosas (registros de compilación, volcados de depuración, cat accidental de archivos enormes) pueden estar realmente limitadas por el rendimiento del terminal.

Tiempo de arranque y latencia

  • A varios usuarios les importa más el tiempo de arranque y la latencia entre pulsación y pantalla que el rendimiento bruto.
  • Algunos informan de arranques casi instantáneos en xfce4-terminal, foot, xterm, kitty (con instancia única), mientras que Ghostty se describe como más lento en algunos sistemas.
  • El autor afirma un seguimiento de daños muy granular y un trabajo mínimo de repintado, sosteniendo una latencia de primer nivel según la implementación, pero no hay mediciones concretas de latencia, y se cuestiona esta afirmación de “trabajo mínimamente necesario” demostrable.

Nombre y adopción

  • El nombre “shitty” polariza: a algunos les parece ingenioso y memorable; otros lo ven como infantil y una barrera para la adopción corporativa.
  • Se debate si evitar blasfemias en los nombres de herramientas importa; algunos dicen que no trabajarían en un lugar donde esto sea un problema, mientras otros enfatizan la profesionalidad.
  • También se critica que los nombres de comandos de dos letras son innecesarios y generan conflictos.

Código generado por IA y calidad

  • Grandes partes del código (incluidas las pruebas) están generadas por LLMs, con revisión humana, sanitizadores (ASan/UBSan), fuzzing y seguimiento de cobertura.
  • Algunos ven esto como un enfoque altamente profesional y basado en pruebas; otros cuestionan la afirmación de que esto sitúa al proyecto en el “0,1% superior” y dudan de cuán a fondo se audita la salida de la IA.

Licencias y preocupaciones sobre GPL

  • El proyecto partió de una base con licencia GPL y pretende pasar a una base de código solo MIT mediante un proceso de reescritura con doble licencia.
  • Los críticos argumentan que esto es legal o éticamente dudoso y que el trabajo sigue derivando de GPL; el autor cita asesoramiento legal e insiste en que el proceso es válido.
  • Surge un debate más amplio sobre copyleft frente a licencias permisivas: si obligar a que los derivados sigan siendo abiertos protege la reciprocidad comunitaria o restringe la libertad del desarrollador.

Funciones, protocolos y arquitectura

  • Actualmente carece de soporte para gráficos y protocolos de teclado modernos (p. ej., sixel, gráficos/teclado de kitty); algunos sostienen que esto hace que las comparaciones con terminales “modernos” sean incompletas.
  • El analizador de salida del terminal está implementado como una gran máquina de estados finitos generada por Ragel, elogiada como un enfoque elegante y de alto rendimiento.
  • La arquitectura, según se informa, separa limpiamente el análisis, la máquina de estados del terminal y el renderizado, lo que hace posible un futuro uso reutilizable al estilo de biblioteca, aunque todavía no se planea una API de “libterminal”.