Entrevista com Mitchell Hashimoto: Ghostty, Zig e manutenção de open source

• Mitchell Hashimoto, depois de Vagrant, Terraform e Vault, criou Ghostty e Vouch, e organiza seus critérios sobre terminais, Zig, manutenção de open source e qualidade de produto
• Ghostty começou como um projeto pessoal para aprender programação de GPU, programação de sistemas de desktop/nó único e Zig, e evoluiu com o objetivo de ser um terminal nativo, multiplataforma, rápido e rico em recursos
• Terminais, em vez de tentar abarcar todos os recursos como navegadores, devem aproveitar a componibilidade de apps baseados em texto, a automação e um modelo de segurança claro; o fluxo de bytes não estruturado do PTY continua sendo uma limitação
• Mantenedores de open source não têm obrigação com usuários, mas, para criar bom software, ele acredita que é preciso resolver várias questões como um recurso coerente, em vez de aceitar pedidos individuais literalmente
• Grandes mudanças no Zig sobrecarregam downstreams, mas elevam a qualidade das APIs e das ferramentas de compilação; ele avalia que a IA pode reduzir o trabalho repetitivo de grandes mudanças e diminuir o peso da compatibilidade retroativa

---

Por que Ghostty começou

• Mitchell Hashimoto criou Vagrant, Packer, Consul, Terraform, Vault, Nomad e Waypoint, e atualmente trabalha em Ghostty e Vouch
• Ghostty nasceu da percepção de que, apesar de ter criado aplicações CLI por cerca de 15 anos, ele não entendia direito como um emulador de terminal funcionava
• Depois de sair da Hashicorp, havia três áreas às quais ele queria voltar
  • Programação de GPU, no contexto anterior à IA
  • Programação de sistemas de desktop/nó único, diferente de sistemas distribuídos
  • Uso de Zig
• O objetivo inicial era rodar vim e um compilador, fazer o Ghostty conseguir compilar a si mesmo e depois descartá-lo
• Ao observar melhor o ecossistema de terminais, concluiu que faltavam ferramentas rápidas, ricas em recursos e nativas multiplataforma
• Depois de compartilhar com amigos no Discord, surgiram usuários diários, e o Discord do Ghostty nasceu de um grupo de amigos convertido em espaço dedicado
• Por acreditar que a visibilidade pública poderia gerar atenção excessiva, manteve o projeto por muito tempo em beta fechado

Até onde um terminal deve se expandir

• Hashimoto é contra empurrar terminais indiscriminadamente na direção de uma enorme plataforma de aplicações
• Um terminal poderia incorporar vídeo, acesso ao microfone e layouts responsivos, como navegadores ou o antigo runtime Java, mas ele acredita que navegadores, desktops e apps em grade monoespaçada baseados em texto têm pontos fortes diferentes
• Aplicações baseadas em texto são rápidas de implementar, fáceis de interagir e devem ter um modelo de segurança claro
• A força dos apps baseados em terminal está na componibilidade
  • Em TUIs isso é menos característico, mas a maioria das ferramentas CLI tem mecanismos que permitem usá-las como funções, além de stdin/stdout
  • A filosofia UNIX de “faça uma coisa e faça bem” está no extremo disso
  • Neovim e ferramentas de IA oferecem cada vez mais flags de linha de comando
• Aplicações de terminal melhores levam a melhor automação e maior possibilidade de scripting
• Sinais in-band no PTY, isto é, fluxos de bytes não estruturados incluindo sequências de escape, continuam sendo um grande problema
• O ecossistema Nushell tenta corrigir isso em uma camada separada, mas Hashimoto acredita que é preciso uma melhoria mais fundamental
• Embora muita gente não goste do ecossistema Microsoft, ele avalia que o PowerShell acerta muita coisa no aspecto de dados estruturados

Ideias para uma API de terminal não legada

• Ao pensar em uma nova API de terminal, Hashimoto toma como referência frameworks de grandes plataformas de aplicação, como navegadores, Emacs, Apple, Microsoft, Android e consoles de jogos
• Ele acredita que é preciso primeiro pesquisar precedentes já acumulados, como o DOM e as APIs JS da Web, AppKit·Cocoa·SwiftUI da Apple, Win32·WinUI do Windows e GTK·Qt do Linux
• Mesmo para acesso à área de transferência, protocolos históricos de terminal são centrados em texto, mas desktops lidam há muito tempo com imagens e vários tipos MIME; por isso, é preciso consultar a documentação de clipboard de cada plataforma
• Ainda não introduziu protocolos customizados no Ghostty

• API n-screen

  • Atualmente, terminais geralmente têm dois tipos de tela: main screen e alt screen
  • A main screen se aproxima do shell e do scrollback, enquanto a alternate screen se aproxima do Neovim e da maioria das TUIs
  • Essa estrutura liga ou desliga um dos dois modos, normalmente ocupando a tela inteira e perdendo o scrollback
  • Hashimoto imagina uma API n-screen capaz de criar e preencher um número ilimitado de telas em segundo plano
  • Cada tela poderia ter um tamanho de grade diferente e ser sobreposta, enquanto o emulador de terminal cuidaria de quebra de linhas, seleção e roteamento de eventos de mouse
  • Se uma tela específica fosse marcada como janela independente, o emulador de terminal também poderia renderizá-la fora da grade
  • Como exemplo, citou uma forma de abrir abas do Neovim simultaneamente como abas nativas de janela

• Protocolo de botões

  • O protocolo de mouse atual só permite receber eventos quando o usuário clica em uma célula da grade da tela atual
  • Não é possível receber eventos de clique em itens de histórico que entraram no scrollback
  • Terminais hoje suportam OSC 8, o protocolo de hyperlinks atual
  • Hashimoto imagina um protocolo de botões que, de modo parecido com OSC 8, envia ao programa uma mensagem definida quando há um clique
  • Por exemplo, um botão com o ID open_profile poderia permanecer registrado mesmo que o usuário role até ele no histórico
  • Esse recurso afetaria aplicações da main screen com scrollback e se relaciona ao problema de apps de main screen como Claude Code, em que abrir arquivos ou links internos do app deixa de funcionar quando esses itens entram no histórico

Ausência de padrões e manutenção de open source

• Hashimoto fez um experimento para substituir todo o protocolo PTY por Wayland, mas o abandonou
• Ele vê o terminal como algo semelhante a um servidor de janelas que gerencia janelas e widgets de janela, e considera Wayland um bom protocolo para resolver problemas de desktop local e renderização de janelas
• Um dos problemas dos terminais é que não há mais um órgão de padronização
• Especificações antigas ainda existem, mas a padronização dos últimos 20 anos foi feita tomando como referência o que o terminal mais popular fazia
• Como resultado, vários recursos se misturaram, e ele acredita que não há uma entidade empurrando uma visão opinativa
• O caminho daqui para frente não está definido; ele considera possível criar um novo espaço de aplicações baseadas em texto, não terminal, e adicionar por cima uma camada de tradução de terminal para apps legados

• Equilíbrio entre demandas de usuários e uma grande visão

  • Hashimoto já disse publicamente que mantenedores de open source têm 0 obrigação com usuários
  • A primeira linha de uma licença open source é “as is, no warranty”, e sua posição é que usuários recebem software gratuito, mas não ganham o direito de fazer exigências
  • Ao mesmo tempo, por querer criar bom software, ele diz sentir responsabilidade de corrigir problemas e tornar o software melhor
  • Em alguns dias, olha issues e corrige problemas de outras pessoas; em outros, não olha issues, discussões ou PRs e se concentra no que ele próprio quer
  • Se passar todos os dias tratando apenas issues de usuários, o software fica estável, mas estagnado; se aceitar todos os PRs, ele muda, mas perde a visão
  • A maioria das contribuições resolve um problema pessoal específico, e aceitar todas elas faz o código se acumular como uma montanha, diz ele
  • Por outro lado, ao entender profundamente um problema, é possível resolver várias solicitações de recursos ao mesmo tempo com um único sistema elegante
  • Em um vídeo de design de recurso, ele deu um exemplo em que fechou 3 ou 4 pedidos individuais de recursos e os resolveu, junto com outro recurso, por meio de uma única solução

• Diferença entre riqueza de recursos e inchaço

  • Busca, um dos recursos mais pedidos no Ghostty, foi implementada e lançada
  • Alguns usuários criticaram a busca por quebrar o minimalismo do Ghostty e inchá-lo, mas Hashimoto respondeu que divulga o Ghostty como um terminal rico em recursos
  • Ele distingue riqueza de recursos de inchaço
  • A busca ocupa espaço em disco e RAM ao ser carregada, mas foi projetada para não executar nenhum código se não for usada
  • Portanto, para usuários que não a usam, ele a vê como um recurso sem custo de execução
  • O Ghostty busca ser um terminal que pode ser personalizado conforme as necessidades do usuário, funciona no estado padrão e esconde recursos até que sejam necessários ou procurados
  • Sobre pedidos para manter uma flag de remoção de recursos, ele considera que exigir que o mantenedor gerencie essa flag e exigir que o usuário mantenha um fork com o recurso removido são o mesmo tipo de demanda

Direitos do open source, mudanças no Zig e qualidade de API

• Hashimoto acredita que deveria haver muito mais forks pessoais e forks mantidos
• Ele considera que o open source financiado por venture capital criou uma geração que espera projetos bem polidos, com site, equipe de suporte pago e suporte em Slack·Discord
• Mas o núcleo do open source não é garantia de produto, e sim liberdade e direitos
  • Usar como quiser
  • Modificar
  • Fazer fork
• Estabilidade ou obrigação de manutenção não fazem parte desses direitos
• Ele diz que um commit que introduz uma vulnerabilidade de segurança não pode ser atribuído apenas ao mantenedor; o usuário também tem responsabilidade por não ter revisado aquele commit
• Sua posição é que, se alguém quer garantias mais fortes e o direito de responsabilizar alguém, deve pagar pelo software e estabelecer uma relação fornecedor-cliente
• Em projetos pessoais, ele pode não mesclar nem mesmo PRs que corrigem bugs que ele próprio não enfrenta
  • Porque fazer merge é uma promessa de manter aquele código para sempre

• Postura em relação ao Zig

  • Hashimoto sabia o que estava aceitando ao escolher Zig e, ao fazer patches no compilador, passou a entender a comunidade, a cultura e a filosofia
  • Ele espera que as mudanças de I/O ainda não iniciadas estejam entre os trabalhos mais difíceis no Zig
  • Embora a popularidade do Zig esteja crescendo, Andrew não recua de mudanças que considera necessárias, e Hashimoto, como usuário downstream, vê isso de forma positiva
  • Zig 0.15 mudou a interface writer e afetou quase todo código que produz saída, mas ele avalia que a API em si ficou muito melhor
  • Zig está focado nas ferramentas de compilação e chegou a remover recursos da linguagem para aumentar a velocidade de compilação
  • É possível compilar imediatamente todo o terminal lib-ghostty, mas Andrew considera até esse tempo em milissegundos lento demais
  • Zig 1.0 chegará algum dia, mas ele acredita que ainda levará alguns anos
  • IA pode reduzir a dor downstream causada por mudanças na linguagem
  • Ele diz que, ao mostrar em vários contextos como fazer uma mudança e depois deixar o restante ser aplicado, cerca de 90% de um diff grande foi tratado automaticamente
  • Se for possível explicar como ir do estado A ao estado B, isso sugere um futuro em que a compatibilidade retroativa perde importância
  • Embora seja irônico diante da forte política anti-IA do Zig, ele acredita que a IA atenua a dor que mudanças causam aos usuários downstream

• Bibliotecas e design de APIs

  • O método mais concreto para criar boas bibliotecas é usar diretamente muitas bibliotecas de várias comunidades
  • Assim como aprender linguagens de programação que você não usará no trabalho real, usar bibliotecas de diferentes ecossistemas amplia a perspectiva
  • Na universidade, ele criou produtos de brinquedo em Prolog, Haskell, Clojure e Java e aprendeu os sistemas de build, usabilidade, bibliotecas, frameworks web, servidores web e servidores de aplicação de cada ecossistema
  • Ele acredita que a cultura de cada ecossistema se infiltra na separação de responsabilidades de bibliotecas e frameworks e no formato das APIs
  • Como exemplo de transplante de conceitos, citou a experiência de tentar em Ruby o padrão builder muito usado em Java e achar que funcionava bem
  • Ele disse que Docker via muitos elementos de implantação e runtime se misturando ao fluxo de desenvolvimento, enquanto Vagrant usava intencionalmente substantivos, CLI e configuração diretamente focados em desenvolvimento

• O dilema do criador de ferramentas e a stack tecnológica

  • Hashimoto diz que foi um criador de ferramentas a vida toda e acredita no dilema do criador de ferramentas
  • O problema é que alguém entende profundamente uma questão e cria uma ferramenta ideal, mas, quando a ferramenta ganha popularidade, pode deixar de ser um usuário real e se tornar um criador de ferramentas sem contato com a realidade; isso pode se repetir
  • Ele usa o próprio terminal todos os dias, mas não desenvolve TUI o suficiente, e depende de mantenedores como rockorager, que mantém vários clientes de e-mail e IRC e também escreve especificações
  • Sobre a stack tecnológica atual, sua atitude é apenas a de que ela é “ok”
  • Ele vê muitos pontos bons em frontend, TypeScript e na comunidade de tipos de React, mas acha que há mudanças demais, complexidade alta e camadas de abstração pouco claras
  • Ele diz que a complexidade cresceu de forma não linear em várias áreas, como na transição de HTTP/1 para HTTP/2 e HTTP/3
  • A indústria se move rápido demais, tornando complexo o que poderia ter sido mais simples, e ele acredita que IA e ferramentas relacionadas aceleram isso

Princípios, cultura, qualidade e aprendizado

• Tanto o documento de princípios da Hashicorp quanto a forma de desenvolver o Ghostty eram reflexos pessoais de Hashimoto, por isso eram fáceis de praticar diariamente
• Ele acredita que, se alguém define princípios diferentes de si mesmo, fica difícil transformá-los em ação real, como resoluções de Ano Novo
• Ghostty valoriza ao mesmo tempo um core multiplataforma e GUIs nativas
  • O core é multiplataforma
  • A GUI não insiste em ser multiplataforma e prefere abordagens nativas de cada plataforma
• Ele acredita que projetos open source e a internet deveriam ser uma coleção de tribos diferentes
• Não gosta que linguagens de programação se tornem entidades de mínimo múltiplo comum com todos os recursos que todo mundo quer, e diz que restrições criam criatividade e cultura
• Disse que gosta da linguagem e da filosofia de Rust, mas não da cultura Rust, distinguindo que isso não significa que as pessoas da comunidade Rust sejam ruins
• Zig tem posições claras e polarizadoras sobre tecnologia, gestão de comunidade, financiamento, PR, posts de blog e forma de se comunicar; Hashimoto diz respeitar essa estranheza e, por isso, continua patrocinando financeiramente e usando Zig
• Para lançar rapidamente com qualidade, é preciso entender não apenas o problema específico de um cliente, mas o contexto em que o usuário chegou até esse problema e os problemas upstream
• Ele diz não saber como resolver isso em escala empresarial, mas, no caso dele, julga como grande usuário do software que cria
• IA pode ser usada de forma bruta para demos ou para validar uma direção, mas o código a ser lançado deve ser lido, entendido e entregue com qualidade
• Sobre aprender C, é mais importante entender como computadores funcionam do que a linguagem em si
  • É preciso entender escalonamento de CPU, memória, hierarquia de cache, sistemas de arquivos, discos e acesso a arquivos
  • Ao trabalhar logo acima da camada de syscalls, em C, Zig ou Rust, fica mais fácil entender o que está acontecendo
  • APIs de abertura de arquivos em Python, JavaScript e Ruby abstraem muitos detalhes
  • Ele aconselha a não tratar funções da biblioteca padrão como algo óbvio: são código escrito por alguém, então é preciso lê-las diretamente e investigar como funcionam

[unsure4000]

Foi postado em um horário parecido, mas é engraçado como o clima é tão diferente kkkkkkk
O que eu penso sobre a reescrita do Bun em Rust

[sea715]

• A maior parte das discussões não é sobre ideias, mas sobre ego
  haha...

[ffdd270]

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

[GN⁺]

Opiniões no Lobste.rs

• Foi uma ótima entrevista, e a melhor frase foi: “Não concordo com tudo, mas respeito muito ser estranho sem vergonha”
  Queria ver mais dessa atitude

• Se vamos falar de precedentes e da evolução do terminal, Arcan e cat9 pelo menos deveriam ser mencionados
  https://arcan-fe.com/2022/04/…

• Na parte em que dizem que “PowerShell lida bem com dados estruturados”, lembrei desta resposta de Jörg W Mittag
  Se você usa argumentos tipados, o parsing fica todo por conta do PowerShell
  A ideia de abas do Neovim abrindo ao mesmo tempo como abas nativas de janela também é muito legal
  Trabalhar logo acima da camada de chamadas de sistema, como em C, Zig e Rust, ajuda muito a entender o que acontece
  O processo de retirar as abstrações entre a máquina e o programador e chegar à camada de base é divertido e te aproxima mais da essência do problema
  Como a biblioteca padrão normalmente busca portabilidade, ela acaba ficando no mínimo denominador comum dos recursos do sistema operacional, mas programar fica muito mais prazeroso quando dá para aproveitar ao máximo a plataforma
  Também respeito muito a postura de não tratar funções da biblioteca padrão como algo óbvio, e sim ler o código, já que foi alguém que escreveu aquilo
  Também queria saber mais sobre o programa de patrocínio do Ghostty. Parece ter sido incorporado como entidade sem fins lucrativos, e fico curioso sobre quão bem-sucedido e sustentável ele é

• O PowerShell no Windows tem a vantagem de ser totalmente interno, segundo esta definição, mas na prática não fica tão limitado porque foi construído sobre o framework .NET e consegue acessar e interoperar com quase toda a API do Windows
  O UNIX é externo por projeto, e a resposta estruturada do Nushell, pelo que entendo, é estritamente interna, então perde em extensibilidade
  O Oils aposta em json ou sua própria extensão, json8, para interoperabilidade estruturada externa, mas ambos ainda parecem bem limitados em comparação com o PowerShell
  Fico pensando em como seria se todos concordassem em mandar apenas algo como msgpack pelo stdout e transformassem todos os terminais em visualizadores de msgpack. Dá até vontade de fazer uma petição para colocar serialização/desserialização de pipes na libc
  Não é só que o órgão de padronização de terminais desapareceu; o mundo dos shells também quase não teve inovação em termos de produção
  O Bash ainda está adicionando recursos que o Kornshell já tinha, os shells Unix têm armadilhas demais que ninguém sabe como remover, e o POSIX mal se move
  Ainda continuo com o sonho de ver Oils ou Nushell adotados pelas principais distribuições e as pessoas perceberem que inovação nessa área é algo bom
  Ainda assim, o kitty claramente ajudou a destravar o espaço dos terminais e, mesmo com pouca coordenação, parece que chegamos a uma fase em que a inovação finalmente está acontecendo

• Passei a respeitar bastante o jeito calmo como Mitchell julga o que é positivo e negativo
  Ele faz um ótimo terminal e gosta de interfaces de terminal, mas não concorda que o terminal deva fazer tudo ou ser levado ao extremo
  Ele se importa profundamente com linguagens de programação e comunidades, e quer que cada linguagem tenha sua identidade própria, mas também sabe que linguagens são meios para um fim e que entender a base é mais importante
  Ele admite não gostar pessoalmente da comunidade Rust, mas sem diminuir quem sente diferente
  É marcante essa postura quase zen de ver a internet como um conjunto de tribos, sem cair no tribalismo nem na busca pela “única tribo verdadeira”

• Concordo com a ideia de que deveria haver mais forks pessoais/de manutenção, mas não sei bem como incentivar isso
  No lado mais baixo do espectro de senso de direito, pode haver quem não tenha interesse em elementos corporativos como contratos de suporte pagos e só queira a conveniência de instalar direto pelo gerenciador de pacotes de que gosta
  Precisamos de algum jeito reduzir o atrito inicial de passar de brew install ou apt install para a etapa de lidar com repositórios clonados e ferramentas de build
  Compiladores mais rápidos podem ajudar
  Por outro lado, em softwares sensíveis à segurança, talvez seja melhor que os usuários não façam mudanças demais, então esse atrito em si às vezes também é uma funcionalidade

• Concordo muito que a UI moderna precisa de algo no meio do caminho entre n-screen e a especificação de botões
  Talvez chamar isso de camada semântica já baste
  Com essa camada, ferramentas do tipo agente, ferramentas de tela principal, acessibilidade e widgets e controles componíveis se tornam possíveis
  No fim, n-screen e botões parecem os limites esquerdo e direito de quanto conteúdo se quer expressar
  No ideal, essa camada semântica também deveria trazer coisas como múltiplos cursores, quebra de linha por palavras em vez de caracteres e overlays (z-index, cell blending etc.)