- El equipo que creó Atom está retomando en Zed el mismo objetivo de un editor ligero pero con funciones de nivel IDE, ahora construido sobre Rust, una UI acelerada por GPU, CRDT y Tree-sitter
- En 2017, las limitaciones de Atom se hicieron más evidentes no por la capacidad del equipo, sino por la falta de control sobre memoria y renderizado en Electron y JavaScript, lo que llevó a la decisión de “volver a empezar”
- Rust permite que Zed maneje memoria compartida y multihilo con mayor seguridad, y con una estructura rope basada en B-tree copy-on-write y
Archace posibles snapshots O(1) para trabajo en segundo plano - Zed decidió poseer directamente capas clave como GPUI, extensiones de Tree-sitter, el crate
editor, multi-buffer y SumTree para obtener control fino, a cambio de asumir una menor velocidad de desarrollo y mayor costo de onboarding - El resultado más importante para el usuario es un editor rápido, y la estructura basada en Rust y
cargofacilita que contribuidores de código abierto prueben builds y cambios, además de aumentar la confianza al fusionar cambios
Cómo la visión de Atom continuó en Zed
- El objetivo de Zed se parece a una versión más refinada de la visión original de Atom
- una herramienta ligera y minimalista, que se sienta como un editor de texto
- una herramienta que ofrezca funciones de nivel IDE cuando se necesiten, pero sin una UI ni una experiencia de uso lentas o pesadas
- un editor extensible y programable mediante scripts
- La extensibilidad de Emacs influyó en la visión inicial, pero querían avanzar hacia una forma de acceder a una representación más rica del texto en lugar de limitarse a manipularlo carácter por carácter
- Tree-sitter es la base que permite tratar el texto de manera estructural y no solo como caracteres, y aunque Zed todavía no es programable mediante scripts, ese sigue siendo el rumbo
- Atom comenzó sobre tecnologías web; en ese momento Rust no existía y también consideraban difícil crear un editor nativo en C o C++
Por qué decidieron “volver a empezar” en 2017
- Después del lanzamiento de Teletype en 2017, el equipo empezó a sentir que el principal cuello de botella ya no era su falta de experiencia, sino las limitaciones de la plataforma
- Los arreglos de JavaScript funcionan como arreglos de punteros a objetos, lo que introduce un costo de seguimiento de punteros al recorrerlos, y además era difícil controlar directamente la disposición de memoria y las pausas del recolector de basura
- Incluso al intentar acelerar el layout de líneas, tenían que combinar de forma indirecta iframes, Canvas y APIs de medición de texto, lo que volvía complejas tareas aparentemente simples como ubicar el cursor o posicionar líneas
- Electron nació para hacer posible Atom, pero era difícil que ofreciera el nivel de control que exige un editor de código
- puede servir para aplicaciones más simples, aunque con la desventaja de una gran huella de memoria
- en un editor de código se necesita un control más directo sobre renderizado, entrada y procesamiento de texto
- En algún momento de 2017 concluyeron que con Atom no podían llegar al nivel que querían, y partieron de la idea de escribir el núcleo en Rust mientras mantenían Electron como capa de presentación
El camino hacia Rust y la aceleración por GPU
- Las decisiones tecnológicas de Zed no siguieron un plano fijo desde el principio, sino que se fueron definiendo al eliminar restricciones paso a paso
- primero evaluaron escribir el núcleo en Rust
- después abandonaron Electron y terminaron creando su propio framework de UI
- usaron Pathfinder, pero como era demasiado lento, aprendieron y aplicaron sus propios shaders y signed distance field
- La aceleración por GPU no surgió tanto del eslogan de un “editor acelerado por GPU”, sino de la idea de que sería más rápido usar directamente hardware capaz de calcular en paralelo el color de cada píxel en pantalla
- En lugar de manipular nodos del DOM, Zed eligió controlar el renderizado en un nivel más cercano a decidir cómo se dibuja cada píxel de la pantalla
- Como ejemplo de mejora de rendimiento,
find-all-matchesantes tardaba alrededor de 1 segundo, mientras que Sublime Text estaba cerca de 200 ms, pero en Zed se redujo hasta 4 ms en build de lanzamiento usando solo código de alto nivel que llama APIs internas - Los tiempos de compilación de Rust siguen siendo una fuente de frustración, pero el hecho de poder esperar buen rendimiento incluso sobre abstracciones de alto nivel ha resultado muy útil para el desarrollo de Zed
La frontera JavaScript/C++ y el multihilo en Rust
- En Atom también usaban mucho C++, pero la frontera entre el código de aplicación en JavaScript y el código de biblioteca en C++ imponía un costo considerable
- para mover trabajo a hilos en segundo plano, había que bajar subsistemas relacionados a C++
- para usar memoria compartida, había que crear una capa en C++ y luego volver a diseñar una API en JavaScript
- también hacía falta mantener una apariencia idiomática de JavaScript sin perder propiedades existentes
- Rust tiene un diseño amigable con el multihilo, por lo que encajaba mejor con la forma en que Zed quería trabajar
- Al principio intentaron implementar en Rust un splay tree mutable con punteros al padre, pero chocaron con el borrow checker al punto de dudar si realmente podrían construir el sistema
- Más adelante crearon un B-tree copy-on-write usando
Arc, y esa estructura resultó naturalmente adecuada para el multihilo - La rope que Zed usa como estructura básica de almacenamiento de texto puede pasar snapshots a hilos en segundo plano simplemente aumentando el conteo de referencias de
Arc
La decisión de poseer directamente todo el stack
- Zed eligió poseer directamente grandes bloques del sistema, desde Tree-sitter para parsing hasta GPUI como framework de UI acelerado por GPU
- Esta estructura de propiedad directa les permite decidir e implementar por sí mismos el comportamiento que necesitan
- cuando quisieron usar WASM en extensiones de lenguaje, pudieron agregar esa capacidad a Tree-sitter
- no tuvieron que delegar a un framework externo de UI una forma de renderizado de texto que es crucial para un editor de texto
- GPUI comenzó en 2019, y los frameworks de UI existentes en ese momento no cumplían con el comportamiento que Zed necesitaba o no eran lo suficientemente comprendidos por el equipo
- Entender directamente los primitivos de bajo nivel y construir el sistema por cuenta propia fue casi una estrategia de supervivencia en el caso de GPUI
- Los costos también son claros
- construirlo por cuenta propia toma mucho tiempo
- la velocidad de desarrollo baja
- al no usar frameworks ampliamente conocidos, el personal nuevo tiene que aprender desde cero una base de código de unas 300 mil líneas
- Al mismo tiempo, como dentro del equipo están quienes escribieron ese código, pueden explicárselo a integrantes nuevos, y consideran que con el tiempo el costo de poseerlo directamente baja mientras sus ventajas se acumulan
- También han aparecido casos de otras aplicaciones construidas sobre GPUI, como loungy
Dónde buscar perfección y dónde avanzar rápido
- El criterio del equipo de Zed es construir solo lo necesario y, dentro de ese alcance, hacerlo lo mejor posible
- En lugar de gastar tiempo adivinando funciones que quizá hagan falta en el futuro, implementan con intención y cuidado lo que realmente se vuelve necesario
- El estándar de calidad cambia según la capa donde esté el código
- capas de las que depende toda la app, como GPUI, requieren un alto nivel de acabado
- estructuras de datos como SumTree, que se usan en todo el codebase y son importantes para el rendimiento, también se tratan con cuidado
- ciertas optimizaciones de rendimiento en los bordes se resuelven al nivel necesario para cumplir su objetivo, sin pulirlas de más
- SumTree usa pruebas aleatorias para verificar edge cases
- El perfeccionismo no debe bloquear el aprendizaje, y cuando se vuelve a escribir algo después de haber operado código propio durante mucho tiempo y haber pasado por sus concesiones, ya existe una base real de aprendizaje para justificar esa reescritura
Lecciones obtenidas de CRDT y de la estructura del buffer
- El buffer inicial de Atom era un arreglo de strings de JavaScript, es decir, un arreglo de líneas
- El buffer de Zed es un B-tree copy-on-write apto para multihilo y con capacidad de snapshots, que indexa varios elementos necesarios
- CRDT no fue una elección obvia desde el principio; la aproximación actual surgió después de una etapa de investigación leyendo varios papers
- La implementación de CRDT se reescribió dos o tres veces, aunque el enfoque general se mantuvo en gran medida
- En Atom, que fue su primer editor de código, usaron una aproximación más rápida y ruda de “worse is better”, y esa experiencia les permitió identificar dónde estaban realmente los puntos de dolor
- Si volvieran a empezar, no construirían el buffer como un simple arreglo de líneas, porque los casos lentos del pasado y los edge cases terminaron exigiendo un diseño más elaborado
Las capas en las que más trabajaron dentro de Zed
- GPUI es una de las áreas donde buscaron un alto nivel de acabado, al haberla reescrito por completo
- El crate
editorincluye varias capas que transforman el texto bruto del buffer en líneas visibles en pantalla- expansión de tabs
- soft wrapping
- inserción de decoraciones de bloque
- manejo de folds
- Estas capas de transformación comparten una estrategia de pruebas consistente basada en pruebas aleatorias con propiedades
- multi-buffer es una estructura que une en una sola vista partes de distintos buffers, y también se trata como una pieza central
- En 2021 hubo ocasiones en que dedicaron varios días completos solo a reducir y depurar edge cases encontrados por las pruebas aleatorias
- La exactitud es importante porque, si esta capa escrita en Rust falla, no aparece simplemente un stack trace en una esquina del editor: el programa puede terminar con un panic
- También discutieron mejoras de carga y de entrada más amigables con streaming para reducir los casos en que el usuario no recibe ninguna retroalimentación al abrir archivos grandes, y optimizaciones relacionadas llegarán a preview
La diferencia que queda para usuarios y contribuidores
- Para el usuario final, al final lo más importante probablemente sea si el editor es rápido
- En herramientas para desarrolladores y editores, existe una alta probabilidad de que los usuarios quieran contribuir directamente al codebase, por lo que el lenguaje de implementación y la forma de build influyen en esa posibilidad
- Si Zed estuviera escrito en C++, quizá habría menos usuarios dispuestos a modificarlo directamente
- Rust y
cargofacilitan compilar el proyecto e intentar cambios, y reducen la necesidad de aprender CMake o Gyp - La rigurosidad del compilador de Rust ayuda a aumentar la confianza al fusionar cambios cuando se reciben contribuciones externas
- Zed quiere mantener los frames por debajo de 3 ms, y por esa exigencia de rendimiento eligió un framework de UI acelerado por GPU en vez de rasterización por CPU
- También hay interés en Zig, pero mantener una estructura de lenguaje único con Rust tanto en el servidor como en el frontend tiene ventajas
1 comentarios
Opiniones en Hacker News
El framework de UI personalizada de Zed puede parecer divertido por ahora, pero creo que la cosa cambiará en cuanto se den cuenta de que tienen que implementar accesibilidad.
Implementar accesibilidad en un framework personalizado sin sacrificar rendimiento requiere mucho trabajo sucio específico de cada plataforma. Zed no se está posicionando simplemente como un editor que uno puede no usar, sino como una herramienta de colaboración, así que es indispensable que todos los desarrolladores del equipo puedan usarla.
Como usuario de lectores de pantalla, estoy cansado de las herramientas “modernas” basadas en Rust en las que VoiceOver solo ve una ventana vacía. Una UI personalizada, que tiene que exponer todos los controles en todos los sistemas operativos, es mucho más difícil que una app web donde basta con poner algunas etiquetas aria en los botones y ordenar el foco.
Por suerte, la aparición de AccessKit, como https://accesskit.dev/, puede facilitar un poco el trabajo, pero no sé qué tan adecuado será para una app grande como un editor.
Como crearon GPUI desde cero, no pueden usar tal cual las funciones de accesibilidad que tienen Swift o las apps basadas en la web, y dicen que harán falta tanto trabajo del lado de Zed como ampliar las capacidades de GPUI.
Pero el enlace que pusieron para la discusión de accesibilidad, https://github.com/zed-industries/zed/pull/1297, es inútil porque lleva a un issue de GitHub sobre los botones de atrás/adelante. Probablemente querían enlazar a https://github.com/zed-industries/zed/discussions/6576.
Documento relacionado: https://zed.dev/docs/themes
Pensaron en la accesibilidad, pero todavía no están en la etapa de haberla implementado de verdad.
Hasta hace no mucho, solo había bindings a frameworks existentes en C o bibliotecas GUI en fase de prueba de concepto. Mejorará con el tiempo, pero entiendo la frustración de quienes dependen de funciones de accesibilidad.
Aun así, es probable que muchos proyectos primero intenten crear una biblioteca GUI sólida y luego agregar funciones de accesibilidad.
Muchas startups han fracasado por invertir recursos en funciones llamativas que ni siquiera eran un diferenciador.
Los productos exitosos con UI no nativa suelen usar tecnologías web o frameworks maduros como Qt, o son excepciones como Blender, que tiene 30 años. Apple también hizo algo parecido con iTunes, pero iTunes para Windows era desagradable, y la gente lo usaba de todos modos.
Entiendo el atractivo de querer crear un framework como GPUI, pero el texto no explica qué relación tiene eso con el problema que Zed intenta resolver.
Me refiero a herramientas que miren solo los píxeles, los entiendan como una persona y parseen el texto con OCR.
Entiendo que tecnologías como VoiceOver conocen y aprovechan a nivel programático la definición real de las ventanas y sus elementos.
Para proyectos que quieren la velocidad del renderizado por GPU y que para VoiceOver se ven como una “ventana vacía”, tal vez este enfoque podría ser al menos una alternativa mínima.
Entonces también me pregunto si eso significa que todo el contenido renderizado por GPU, como en los juegos, es inaccesible.
En el iPhone tengo creado un atajo de Apple llamado “GPT Explains”: con dos toques en la parte trasera del teléfono toma una captura, la envía a OpenAI y me devuelve una explicación de lo que se ve, traducción al inglés de texto que no esté en inglés, refutaciones de afirmaciones en memes, etc.
Hay una copia sin la API key aquí: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Antes de subirse a la moda de los nuevos editores de texto, dejo esto para que le echen un vistazo a la licencia que el usuario debe aceptar.
“Los Customer Data, compuestos por el contenido de usuario generado durante el uso de la Solution, se clasifican como User Content. El User Content se transmite desde el entorno del usuario solo cuando se elige compartir un proyecto en el Editor para colaborar con otros usuarios de Zed.”
“[...] el acceso de Zed a dicho User Content se limita a depuración y mejora de la Solution.”
No voy a agregar interpretación; que cada quien saque sus propias conclusiones.
Si elegiste compartir un proyecto con otra persona para colaborar, es obvio que el contenido de ese proyecto se transmite fuera de tu máquina. ¿Cómo funcionaría si no?
Probé Zed por este artículo y me pareció bastante prometedor. Pero no puedo usarlo porque no soporta hosts remotos/devcontainer
Esta función de VSCode es central para mi flujo de trabajo. En realidad no quiero desarrollar en la Mac; quiero usar la Mac como un portal hacia las VM y contenedores donde programo
Ayuda mucho a separar proyectos, y también mejora la seguridad porque no dejo el entorno de desarrollo ni las dependencias en la máquina host real
Me da curiosidad qué ventajas ofrecen los hosts remotos/devcontainer de VSCode frente a una sesión remota normal
Es una entrevista excelente, muy recomendable, porque permite ver muy bien la forma de pensar de los desarrolladores y cómo miran el desarrollo desde varios ángulos
Aunque tengo una discrepancia
No es que “Zed ya se quedó con el nombre perfecto para un editor de texto hecho en Zig”; ese nombre es “Zag” ;)
zedcontieneed.edes el precursor deex,viyedlin, y es un editor de líneas de la familia Unix que todavía existehttps://en.wikipedia.org/wiki/Ed_(text_editor)
En cambio
ag, es decir, the silver searcher, también es excelente, pero veo a Zed más cerca de la edición de código que de la búsqueda de códigohttps://geoff.greer.fm/ag/
No uso Zed, pero vi a José Valim usarlo en live coding. Uso principalmente VSCode, y una función que vi en Zed me resultó bastante atractiva
Al hacer “Find All”, aparece en el panel de resultados un fragmento de todos los archivos coincidentes, como en VSCode, pero ahí se podían editar directamente los fragmentos de resultados de búsqueda, y también usar tal cual funciones normales de edición como multicursor
En VSCode hay que hacer clic en el resultado de búsqueda para abrir el archivo y modificarlo ahí, así que me pareció algo bastante bueno e impresionante. No fue suficiente para cambiarme, pero me viene a la mente de vez en cuando cuando VSCode me irrita
occurymulti-occurdesde los años 80, y permite hacer ese tipo de trabajo. Es realmente excelenteMás recientemente, las interfaces para herramientas como ripgrep también ofrecen un modo editable, muy conveniente para refactorizar. Por supuesto, también se pueden editar nombres de archivos en bloque
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...
Puede sonar absurdo, pero una de las principales razones por las que uso JetBrains en lugar de VSCode es que puedo buscar en un directorio y abrirlo en el panel de navegación
Solo al ver este comentario recordé que existía, así que tendré que volver a probarlo
https://marketplace.visualstudio.com/items?itemName=jakearl....
Uno de mis trucos favoritos es editar con multicursor y usar los atajos para ir al final de la línea o a la siguiente palabra, y así hacer cambios masivos
Sería bueno poder hacerlo en varios archivos
No funciona en Windows ni en Linux. Me gustaría que avisaran cuando lo soporten
Excelente entrevista
Me gustó que pensaran a fondo en qué cosas pulir en exceso. Siento que mis mejores trabajos también suelen haber salido en la segunda, tercera o cuarta ronda
Me pregunto qué planes hay para manejar la configuración con scripts. Todavía no he usado mucho Zed; ¿ya es posible hoy? ¿Algo como Neon ayudaría a cerrar la brecha entre VSCode y los antiguos usuarios de Atom?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
Siempre es interesante ver una v2. He visto casos en los que se convierte en un desastre por sobrecarga de funciones, y otros en los que se vuelve excelente por ser más simple y ágil
En el campo de las apps web actuales hay tantas herramientas que me pregunto si este riesgo aplica igual no solo a la v2 sino también a la v1. He visto muchas v1 sorprendentemente infladas últimamente, y a menudo uno tiene que buscar deliberadamente herramientas que hagan menos
Probé Zed y se sintió parecido a VSCode. Sé que tiene una función multijugador mejor que Live Share, pero visto desde afuera me hacía falta algo más convincente para cambiarme
Si Zed pudiera reemplazar a Xcode, creo que me darían más ganas de probarlo. Desde borrar derived data o limpiar el build folder hasta crasheos aleatorios, usar Xcode es doloroso
Comparado con la experiencia de desarrollo de Android Studio, es totalmente distinto. En el desarrollo iOS siempre quise una experiencia como la de Android Studio
Me encantan las apps nativas, pero ahora estoy atado a VS Code. Me duele ver que en VS Code hasta el parpadeo del cursor consume bastante energía
Probé Zed un rato, pero no logré adaptarlo a mi flujo de trabajo. Me gustó que fuera liviano y rápido. Los procesos de VS Code rondan los 3 GB, mientras que Zed usa 300 MB, así que una décima parte de la memoria es una diferencia significativa
Pero necesito sí o sí el soporte para Jupyter Notebook que ofrece VS Code, y ya estoy demasiado acostumbrado a desarrollar en remoto desde una Mac hacia una máquina Ubuntu. VS Code hace eso muy bien
Espero que Zed aguante lo suficiente como para llegar a soportar mi flujo de trabajo
Tal vez los demás tengan muchas más extensiones activadas
Según el efecto Lindy https://en.wikipedia.org/wiki/Lindy_effect, parece que faltará al menos otro año para ver algo
Vi la página About y la función de live coding parece útil. Imagino que los desarrolladores también estarán entusiasmados. Es un proyecto interesante: permite trabajar con algoritmos, optimizar rendimiento y hacer programación con GPU
Pero me pregunto quién necesita otro editor de texto que probablemente nunca alcance paridad funcional con Vim y un multiplexor de terminal
VS Code apareció de pronto hace relativamente poco y mucha gente lo usa, así que demuestra que después de Vim también había oportunidades para editores nuevos
Está por verse si Zed ganará suficiente impulso como para cubrir la larga cola de necesidades de otros desarrolladores, pero me entusiasma bastante que aparezcan más productos compitiendo por usuarios
Sin tener que imitar a Vim, podrían aprovechar Neovim y todos sus plugins tal cual
Todavía me da pena que JetBrains siga manteniendo un plugin que imita Vim y que los usuarios de Vim llaman pésimo. Si implementaran de forma nativa un frontend de Neovim en el IDE, tendrían una ventaja mucho más fuerte: “soporte completo para Neovim y su ecosistema”. En cambio, ahora se quedan en “hay un plugin parecido a Vim”
Usa la herramienta que te guste y que te permita terminar el trabajo. Eso incluye Vim, pero ya me cansé de que se actúe como si usar Vim fuera una bendición insustituible
Convertirse en alguien que piensa mejor aumenta exponencialmente la productividad como programador más que cualquier herramienta
Ya existen editores con bastantes funciones, con los que la gente está satisfecha o al menos acostumbrada. ¿Dónde podría hacerse un lugar un editor nuevo?
Lo de “multijugador” está genial, pero se acerca más a un caso extremo
Tampoco me convence el modelo de negocio. ¿La gente realmente quiere que canales, llamadas y chat estén integrados en el editor de código? Personalmente me genera un rechazo casi instintivo, aunque tal vez sea solo yo