Temos que recomeçar: de Atom a Zed
(zed.dev)- A equipe que criou o Atom está retomando no Zed o mesmo objetivo de um editor leve, mas com recursos de nível IDE, agora com base em Rust · UI acelerada por GPU · CRDT · Tree-sitter
- Em 2017, as limitações do Atom ficaram mais evidentes menos pela capacidade da equipe e mais pela falta de controle sobre memória e renderização no Electron e no JavaScript, o que levou à conclusão de que “era preciso recomeçar”
- O Rust permite que o Zed lide com memória compartilhada e multithreading com mais segurança, e sua estrutura de rope baseada em B-tree copy-on-write e
Arcviabiliza snapshots O(1) necessários para tarefas em segundo plano - O Zed optou por possuir diretamente camadas centrais como GPUI, extensões do Tree-sitter, o crate
editor, multi-buffer e SumTree para obter controle fino, aceitando em troca menor velocidade de desenvolvimento e maior custo de onboarding - O resultado mais importante para o usuário é um editor rápido, e a estrutura baseada em Rust e
cargofacilita que contribuidores open source tentem compilar e modificar o projeto, além de aumentar a confiabilidade na integração de mudanças
Como a visão do Atom continuou no Zed
- O objetivo do Zed está mais próximo de uma forma refinada da visão que o Atom buscava no início
- uma ferramenta leve, minimalista e com sensação de editor de texto
- uma ferramenta que ofereça recursos de nível IDE quando necessário, sem que a UI e a experiência de uso fiquem lentas ou pesadas
- um editor extensível e scriptável
- A extensibilidade do Emacs influenciou a visão inicial, mas a direção desejada era acessar representações de texto mais ricas, em vez de apenas manipular texto no nível de caracteres
- O Tree-sitter é a base que permite tratar texto de forma estrutural, e não apenas por caracteres; o Zed ainda não é scriptável, mas segue nessa direção
- O Atom começou com base em tecnologias web; na época, Rust ainda não existia, e a equipe considerava difícil também criar um editor nativo em C ou C++
Por que decidiram “recomeçar” em 2017
- Em 2017, após lançar o Teletype, o Atom começou a sentir que o maior gargalo vinha mais das restrições da plataforma do que da imaturidade da equipe
- Arrays em JavaScript funcionavam como arrays de ponteiros para objetos, gerando custo de pointer chasing durante iteração, e era difícil controlar diretamente o layout de memória e as pausas do garbage collector
- Mesmo ao tentar acelerar a criação do layout de linhas, era preciso combinar iframe, Canvas e APIs de medição de texto de forma indireta, o que tornava complexas até tarefas aparentemente simples, como posição do cursor e disposição das linhas
- O Electron nasceu para viabilizar o Atom, mas era difícil que oferecesse o nível de controle exigido por um editor de código
- Ele pode servir para aplicativos mais simples, mas tem a desvantagem de um grande consumo de memória
- Em editores de código, é preciso controle mais direto sobre renderização, entrada e processamento de texto
- Em algum momento de 2017, ficou claro que o Atom não chegaria ao nível desejado; a ideia inicial foi escrever o núcleo em Rust, mantendo o Electron como camada de apresentação
Como aconteceu a migração para Rust e aceleração por GPU
- As escolhas tecnológicas do Zed não vieram de um plano fixo desde o começo, mas foram sendo definidas passo a passo, removendo restrições
- primeiro, foi considerada a direção de escrever o núcleo em Rust
- depois, o Electron foi abandonado e a equipe passou a criar seu próprio framework de UI
- usaram o Pathfinder, mas como ele era lento demais, estudaram e aplicaram shaders próprios e signed distance field
- A aceleração por GPU não surgiu de um slogan do tipo “editor acelerado por GPU”, mas da avaliação de que seria mais rápido usar diretamente um hardware capaz de calcular em paralelo a cor de cada pixel da tela
- Em vez de ajustar nós do DOM, o Zed escolheu controlar a renderização em um nível mais próximo de como os pixels da tela devem ser desenhados
- Como exemplo de ganho de desempenho,
find-all-matcheslevava antes cerca de 1 segundo, enquanto o Sublime Text ficava perto de 200 ms; no Zed, isso caiu para 4 ms em build de release, usando apenas código de alto nível que chama APIs internas - O tempo de compilação do Rust continua sendo um ponto de insatisfação, mas a possibilidade de esperar desempenho mesmo sobre abstrações de alto nível tem sido útil no desenvolvimento do Zed
A fronteira JavaScript/C++ e o multithreading no Rust
- O Atom também usava muito C++, mas a fronteira entre o código da aplicação em JavaScript e o código de biblioteca em C++ funcionava como um custo elevado
- para mover trabalho para threads em segundo plano, era preciso levar subsistemas relacionados para C++
- para usar memória compartilhada, era necessário criar uma camada em C++ e depois redesenhar a API em JavaScript
- também era preciso fazer isso parecer idiomático em JavaScript, mantendo propriedades existentes
- O Rust tem um desenho mais amigável para multithreading, o que se encaixa melhor na forma como o Zed queria trabalhar
- No início, houve a tentativa de implementar em Rust uma splay tree mutável com ponteiros para o pai, mas isso entrou em conflito com o borrow checker, a ponto de gerar dúvida sobre a viabilidade de construir o sistema real
- Depois, ao criar uma B-tree copy-on-write, a equipe passou a usar
Arc, e essa estrutura acabou se mostrando naturalmente adequada ao multithreading - A rope usada pelo Zed como estrutura básica de armazenamento de texto pode ser passada para threads em segundo plano basicamente aumentando a contagem de referência de
Arcao criar um snapshot
A escolha de possuir diretamente toda a stack
- O Zed escolheu possuir diretamente grandes blocos, do Tree-sitter responsável pelo parsing até o GPUI, seu framework de UI acelerado por GPU
- Uma estrutura sob controle direto permite definir e implementar por conta própria o comportamento necessário
- quando quiseram usar WASM em extensões de linguagem, puderam adicionar esse recurso ao Tree-sitter
- não precisam delegar a um framework de UI externo a forma de renderização de texto, algo crucial para um editor de texto
- O GPUI começou em 2019, e os frameworks de UI existentes na época ou não atendiam ao comportamento necessário para o Zed, ou não eram suficientemente compreendidos pela equipe
- Entender diretamente os primitivos de baixo nível e construir o sistema a partir deles era quase uma estratégia de sobrevivência no caso do GPUI
- O custo também é claro
- leva muito tempo para construir internamente
- a velocidade de desenvolvimento diminui
- como não usam um framework amplamente conhecido, novos integrantes precisam aprender do zero um codebase de cerca de 300 mil linhas
- Ao mesmo tempo, há pessoas na equipe que escreveram esse código e podem explicá-lo aos novos membros; com o tempo, o custo de possuir isso diretamente tende a cair, enquanto as vantagens podem se acumular
- Também já surgiram casos de outros apps construídos sobre o GPUI, como o loungy
Onde buscar acabamento e onde avançar rápido
- O critério da equipe do Zed é construir apenas o necessário e, dentro desse escopo, fazer isso o melhor possível
- Em vez de gastar tempo tentando adivinhar funcionalidades que talvez sejam necessárias no futuro, a equipe implementa com intenção e atenção aquilo que realmente se torna necessário
- O padrão de acabamento varia conforme a camada em que o código está
- camadas das quais o aplicativo inteiro depende, como o GPUI, exigem alto grau de acabamento
- estruturas de dados como o SumTree, usadas em todo o codebase e sensíveis a desempenho, também são tratadas com cuidado
- otimizações específicas de borda são resolvidas no nível suficiente para cumprir o objetivo, sem lapidação excessiva
- O SumTree usa testes aleatórios para verificar edge cases
- O perfeccionismo não deve atrapalhar o aprendizado; quando se reescreve algo após operar por muito tempo um código próprio e viver seus trade-offs, passa a haver base real para uma reimplementação que incorpora esse aprendizado
Lições obtidas com CRDT e com a estrutura dos buffers
- O buffer inicial do Atom era um array de strings em JavaScript, ou seja, um array de linhas
- O buffer do Zed é uma B-tree copy-on-write amigável a multithreading e passível de snapshot, com indexação de vários itens necessários
- O CRDT não foi uma escolha óbvia desde o começo; a abordagem atual foi consolidada após um período de pesquisa com leitura de diversos artigos
- A implementação de CRDT foi reescrita duas ou três vezes, mas a abordagem em si foi em grande parte mantida
- No Atom, que foi seu primeiro editor de código, a equipe usou uma abordagem mais rápida e mais áspera, de “worse is better”, e essa experiência ajudou a identificar onde estavam os verdadeiros pontos de dor
- Se fossem recomeçar, não fariam o buffer como um simples array de linhas; os exemplos antigos de lentidão e os edge cases levaram a um design mais robusto
Camadas às quais o Zed dedicou atenção especial
- O GPUI é uma área em que se buscou alto grau de acabamento, já que foi totalmente reescrito
- O crate
editorinclui várias camadas que transformam o texto bruto do buffer em linhas exibidas na tela- expansão de tabulações
- soft wrap
- inserção de block decorations
- tratamento de folds
- Essas camadas de transformação compartilham uma estratégia consistente de testes, com testes aleatórios baseados em propriedades
- O multi-buffer é uma estrutura que combina partes de buffers diferentes em um só, e também é tratado como componente central
- Em 2021, houve ocasiões em que vários dias foram dedicados inteiramente a reduzir e depurar edge cases encontrados por testes aleatórios
- Como essas camadas são escritas em Rust, se algo estiver errado o programa pode entrar em pânico e encerrar, em vez de apenas mostrar um stack trace num canto do editor; por isso, a correção é crucial
- Também foram discutidas melhorias de entrada e carregamento mais amigáveis a streaming para reduzir o tempo em que o usuário fica sem feedback ao abrir arquivos grandes, e otimizações relacionadas devem entrar em preview
A diferença percebida por usuários e contribuidores
- Para o usuário final, no fim das contas o mais importante tende a ser se o editor é rápido
- Em ferramentas de desenvolvimento e editores, há maior chance de que os próprios usuários contribuam com o codebase, então a linguagem de implementação e a forma de build influenciam essa possibilidade de contribuição
- Se o Zed fosse escrito em C++, talvez menos usuários tentassem modificá-lo diretamente
- Rust e
cargofacilitam compilar o projeto e experimentar mudanças, reduzindo a necessidade de aprender CMake ou Gyp - O rigor do compilador Rust ajuda a aumentar a confiabilidade na integração de contribuições externas
- O Zed quer manter os frames abaixo de 3 ms, e essa exigência de desempenho foi um motivo para escolher um framework de UI acelerado por GPU em vez de rasterização por CPU
- Há interesse em Zig, mas existe vantagem em uma estrutura de linguagem única em que servidor e frontend são ambos em Rust
1 comentários
Opiniões no Hacker News
O framework de UI customizado do Zed pode parecer interessante agora, mas acho que a situação muda no momento em que eles perceberem que precisam implementar acessibilidade.
Implementar acessibilidade em um framework customizado sem sacrificar desempenho exige muito trabalho complicado específico de cada plataforma. Como o Zed se posiciona não apenas como um editor que você pode simplesmente não usar, mas como uma ferramenta de colaboração, é essencial que todos os desenvolvedores de uma equipe consigam usá-lo.
Como usuário de leitor de tela, estou cansado de ferramentas “modernas” baseadas em Rust em que o VoiceOver só enxerga uma janela vazia. Uma UI customizada, que precisa expor todos os controles a todos os sistemas operacionais, é muito mais difícil do que uma aplicação web em que bastaria colocar alguns rótulos aria em botões e organizar o foco.
Felizmente, algo como o AccessKit, em https://accesskit.dev/, surgiu e pode facilitar um pouco o trabalho, mas não sei o quanto ele é adequado para um app grande como um editor.
Como eles criaram o GPUI do zero, não podem simplesmente aproveitar os recursos de acessibilidade que apps baseados em Swift ou na web já têm, e dizem que será necessário tanto trabalho do lado do Zed quanto a expansão de recursos do GPUI.
Só que o link que colocaram para a discussão sobre acessibilidade, https://github.com/zed-industries/zed/pull/1297, é uma issue do GitHub relacionada a botões de voltar/avançar, então não serve para nada. Provavelmente queriam linkar https://github.com/zed-industries/zed/discussions/6576.
Documentação relacionada: https://zed.dev/docs/themes
Eles pensaram em acessibilidade, mas ainda não estão em uma etapa em que ela esteja realmente implementada.
Até pouco tempo atrás, só havia bibliotecas GUI que eram bindings de frameworks C existentes ou estavam em estágio de prova de conceito. Isso deve melhorar daqui para a frente, mas entendo a frustração de quem depende de recursos de acessibilidade.
Dito isso, é bem provável que muitos projetos tentem primeiro criar uma biblioteca GUI sólida e só depois adicionar recursos de acessibilidade.
Muitas startups fracassaram ao gastar recursos em funcionalidades chamativas que nem eram seu diferencial.
Produtos que tiveram sucesso com UI não nativa geralmente usam tecnologias web ou frameworks maduros como Qt, ou então são exceções como o Blender, que tem 30 anos. A Apple também fez algo parecido no iTunes, mas o iTunes para Windows era desagradável; as pessoas simplesmente usavam o iTunes apesar disso.
Entendo o apelo de criar um framework como o GPUI, mas o texto não explica que relação isso tem com o problema que o Zed está tentando resolver.
Falo de ferramentas que olhem apenas os pixels e entendam como uma pessoa, fazendo OCR para analisar o texto.
Pelo que entendo, tecnologias como o VoiceOver conhecem e aproveitam, em nível programático, a definição real da janela e seus elementos.
Para projetos que querem a velocidade da renderização por GPU e aparecem para o VoiceOver como uma “janela vazia”, talvez essa abordagem pudesse ser ao menos uma alternativa mínima.
Se for assim, também fico pensando se isso significa que todo conteúdo renderizado por GPU, como em jogos, é inacessível.
Criei um atalho da Apple chamado “GPT Explains” no iPhone: com dois toques na traseira do celular, ele tira uma captura de tela, envia para a OpenAI e recebe de volta uma descrição do que aparece, tradução para o inglês de textos que não estejam em inglês, refutações de alegações em memes etc.
Uma cópia sem a chave de API está aqui: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Antes de entrar na moda de mais um editor de texto novo, deixo aqui a sugestão de dar uma olhada na licença com a qual o usuário precisa concordar.
“Customer Data, composto por conteúdo de usuário gerado durante o uso da Solution, é classificado como User Content. User Content só é transmitido para fora do ambiente do usuário quando você opta por compartilhar um projeto no Editor para colaborar com outros usuários do Zed.”
“[...] o acesso da Zed a esse User Content é limitado à depuração e à melhoria da Solution.”
Não vou acrescentar interpretação; cada um tire suas próprias conclusões.
Se você escolheu compartilhar um projeto com outra pessoa para colaborar, é óbvio que o conteúdo desse projeto será transmitido para fora da sua máquina. Como funcionaria de outro jeito?
Por causa deste texto, experimentei o Zed, e ele me pareceu bastante promissor. Mas não consigo usá-lo porque ele não oferece suporte a host remoto/devcontainer
Esse recurso do VSCode é central para o meu fluxo de trabalho. Na prática, não quero desenvolver no Mac; quero usar o Mac como um portal para as VMs e contêineres onde eu programo
Isso ajuda muito a separar projetos e também é melhor do ponto de vista de segurança, já que não mantenho o ambiente de desenvolvimento nem dependências na máquina host real
Fico curioso sobre qual é a vantagem do host remoto/devcontainer do VSCode em relação a uma sessão remota comum
Recomendo muito: é uma entrevista excelente, que permite enxergar bem a mentalidade de como desenvolvedores veem o desenvolvimento por vários ângulos
Só tenho uma discordância
Não é que “o nome perfeito para um editor de texto feito em Zig já foi pego pelo Zed”; esse nome é “Zag” ;)
zedcontémed.edé o precursor deex,vieedlin, e é um editor de linha da família Unix que ainda existehttps://en.wikipedia.org/wiki/Ed_(text_editor)
Já
ag, ou seja, the silver searcher, também é excelente, mas vejo o Zed mais como algo voltado à edição de código do que à busca de códigohttps://geoff.greer.fm/ag/
Não uso o Zed, mas vi José Valim usando em live coding. Uso principalmente VSCode, e um recurso que vi no Zed me pareceu bem atraente
Ao fazer “Find All”, como no VSCode, aparecem no painel de resultados trechos de todos os arquivos correspondentes, mas ali era possível editar diretamente os trechos dos resultados da busca, mantendo também recursos comuns de edição, como multicursores
No VSCode é preciso clicar no resultado da busca, abrir o arquivo e editar lá, então achei bem legal e impressionante. Não foi o suficiente para eu migrar, mas lembro disso de vez em quando, sempre que o VSCode me irrita
occuremulti-occurdesde os anos 80, e permite esse tipo de coisa. É realmente excelenteMais recentemente, interfaces para ferramentas como ripgrep também oferecem modos editáveis, o que é muito conveniente para refatoração. Claro, também dá para editar nomes de arquivos em lote
https://www.masteringemacs.org/article/searching-buffers-occ...
https://rgel.readthedocs.io/en/latest/
https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
Pode parecer absurdo, mas um dos principais motivos pelos quais uso JetBrains em vez de VSCode é poder buscar diretórios e abri-los no painel de navegação
Só me lembrei disso, que tinha esquecido, depois de ler este comentário, então vou tentar usar de novo
https://marketplace.visualstudio.com/items?itemName=jakearl....
Um dos truques de que gosto é editar com multicursores e usar atalhos para ir ao fim da linha ou à próxima palavra para fazer alterações em massa
Seria bom poder fazer isso em vários arquivos
Não funciona no Windows nem no Linux. Gostaria que avisassem de novo quando houver suporte
Excelente entrevista
Gostei de como ele pensa profundamente sobre o que polir em excesso. Acho que meus melhores trabalhos também costumam ter surgido lá pela segunda, terceira ou quarta rodada
Fico curioso sobre quais são os planos para tratar a configuração por scripts. Ainda não usei muito o Zed; isso já é possível hoje? Algo como o Neon poderia ajudar a fechar a lacuna entre o VSCode e os antigos usuários do Atom?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
É sempre interessante ver uma v2. Já vi casos em que virou um desastre por excesso de recursos, e casos em que ficou excelente por se tornar mais simples e ágil
Hoje há tantas ferramentas no campo de apps web que me pergunto se esse risco não se aplica igualmente à v1, não só à v2. Tenho visto muitas v1 surpreendentemente inchadas, e muitas vezes é preciso procurar deliberadamente ferramentas que façam menos
Testei o Zed e ele me pareceu parecido com o VSCode. Sei que ele tem um recurso multiplayer melhor que o Live Share, mas, visto de fora, ainda faltou algo mais convincente para eu trocar
Se o Zed pudesse substituir o Xcode, eu provavelmente teria vontade de usá-lo mais. De apagar derived data e limpar a build folder até crashes aleatórios, usar o Xcode é sofrido
Comparado à experiência de desenvolvimento do Android Studio, é outra coisa completamente diferente. Sempre quis uma experiência tipo Android Studio também no desenvolvimento iOS
Eu realmente gosto de apps nativos, mas hoje estou preso ao VS Code. Dá uma dor ver que até o piscar do cursor no VS Code consome bastante energia
Usei o Zed por um tempo, mas não consegui adaptá-lo ao meu fluxo de trabalho. Gostei de ele ser leve e rápido. Os processos do VS Code ficam em torno de 3 GB, enquanto o Zed fica em 300 MB, então um décimo da memória é uma diferença significativa
Mas eu preciso muito do suporte a Jupyter Notebook que o VS Code oferece, e também já estou acostumado demais a fazer desenvolvimento remoto do Mac para uma máquina Ubuntu. O VS Code faz isso muito bem
Espero que o Zed aguente tempo suficiente para passar a dar suporte ao meu fluxo de trabalho
Talvez todo mundo tenha mais extensões ativadas
Segundo o efeito Lindy https://en.wikipedia.org/wiki/Lindy_effect, parece que ainda vai levar mais um ano até vermos algo
Vi a página About, e o recurso de live coding parece útil. Os desenvolvedores também devem estar empolgados. É um projeto divertido, em que dá para usar algoritmos, otimizar desempenho e fazer programação de GPU
Mas fico pensando quem precisa de mais um editor de texto que provavelmente nunca vai alcançar paridade de recursos com o Vim e multiplexadores de terminal
O VS Code apareceu de repente há relativamente pouco tempo e muita gente o usa, então ele mostra que ainda havia espaço para novos editores depois do Vim
Resta ver se o Zed vai ganhar tração suficiente para atender à longa cauda de demandas de outros desenvolvedores, mas é bem animador ver mais produtos competindo por usuários
Sem precisar imitar o Vim, daria para aproveitar o Neovim e todos os plugins exatamente como são
Ainda acho uma pena que a JetBrains continue mantendo um plugin que imita Vim e que usuários de Vim chamam de péssimo. Se eles implementassem nativamente um front-end do Neovim no IDE, teriam uma vantagem muito mais forte, de “suporte completo ao Neovim e ao seu ecossistema”; hoje fica só em “tem um plugin parecido com Vim”
Use a ferramenta de que você gosta e que permite concluir o trabalho. Isso inclui o Vim, mas estou cansado de tratarem o uso do Vim como se fosse uma bênção insubstituível
Tornar-se alguém que pensa melhor aumenta exponencialmente a produtividade como programador mais do que qualquer ferramenta
Já existem editores bem ricos em recursos, com os quais as pessoas estão satisfeitas ou pelo menos acostumadas. Onde um novo editor poderia se encaixar?
“Multiplayer” é legal, mas está mais para um caso de borda
Também não tenho convicção sobre o modelo de negócios. As pessoas realmente querem canais, chamadas e chat integrados ao editor de código? Pessoalmente, tenho uma rejeição quase instintiva a isso, mas talvez seja só eu