Show HN: Shitty – terminal rápida. Insegura em memória e mais rápida que a sua

Reivindicações do projeto e de desempenho

• Novo emulador de terminal multiplataforma focado em máxima vazão e escrito em C++ (explicitamente “inseguro em memória”, ou seja, não Rust).
• Os benchmarks mostram vazão ASCII significativamente maior do que a de terminais populares (Ghostty, kitty, alacritty, GNOME Terminal, etc.).
• Usa um nome binário de duas letras st, sobrepondo-se a um terminal existente e levantando preocupações de colisão.

Valor prático vs. superotimização

• Muitos comentaristas dizem que raramente se sentem limitados pelo desempenho do terminal e, em vez disso, priorizam recursos, integração e estabilidade.
• Vários argumentam que a economia de tempo ao longo da vida útil com maior vazão é minúscula comparada ao custo de trocar de terminal.
• Outros observam que cargas de trabalho com saída extremamente verbosa (logs de build, dumps de depuração, cat acidental de arquivos enormes) podem ser limitadas de forma relevante pela vazão do terminal.

Tempo de inicialização e latência

• Vários usuários se importam mais com o tempo de inicialização e a latência do pressionamento de tecla até a tela do que com a vazão bruta.
• Alguns relatam inicialização quase instantânea em xfce4-terminal, foot, xterm, kitty (com instância única), enquanto o Ghostty é descrito como mais lento em alguns sistemas.
• O autor afirma ter rastreamento de danos de granularidade muito fina e trabalho mínimo de redesenho, sustentando latência de primeira linha com base na implementação, mas não há medições concretas de latência, e essa alegação de “trabalho mínimo comprovável” é questionada.

Nome e adoção

• O nome “shitty” é polarizador: alguns o acham engenhoso e memorável; outros o veem como juvenil e uma barreira à adoção corporativa.
• Há debate sobre se evitar palavrões em nomes de ferramentas importa; alguns dizem que não trabalhariam onde isso fosse um problema, outros enfatizam o profissionalismo.
• A nomenclatura de comandos com duas letras também é criticada como desnecessária e conflitiva.

Código gerado por IA e qualidade

• Grandes partes do código (incluindo testes) são geradas por LLMs, com revisão humana, sanitizers (ASan/UBSan), fuzzing e acompanhamento de cobertura.
• Alguns veem isso como uma abordagem altamente profissional e orientada a testes; outros questionam a दावा de que isso coloca o projeto no “top 0,1%” e duvidam de quão minuciosamente a saída da IA é auditada.

Licenciamento e preocupações com GPL

• O projeto começou a partir de uma base licenciada sob GPL e pretende migrar para uma base de código somente MIT por meio de um processo de reescrita com dupla licença.
• Críticos argumentam que isso é juridicamente ou eticamente duvidoso e que o trabalho ainda é derivado da GPL; o autor cita aconselhamento jurídico e insiste que o processo é válido.
• Surge um debate mais amplo sobre copyleft vs. licenças permissivas: se forçar a abertura de derivados protege a reciprocidade da comunidade ou restringe a liberdade do desenvolvedor.

Recursos, protocolos e arquitetura

• Atualmente não há suporte para protocolos modernos de gráficos e teclado (por exemplo, sixel, kitty graphics/keyboard); alguns argumentam que isso torna as comparações com terminais “modernos” incompletas.
• O parser de saída do terminal é implementado como uma grande máquina de estados finitos gerada por Ragel, elogiada como uma abordagem elegante e performática.
• A arquitetura, segundo relatos, separa de forma limpa parsing, máquina de estados do terminal e renderização, tornando possível uma futura reutilização no estilo de biblioteca, embora ainda não haja um API “libterminal” planejado.