Github has pushed the limits of collaboration in coding as a platform for discussing, sharing, and participating in code and projects. Yet, new tools are looking to push the limit even forward. Zed is a collaborative code editor that offers real-time interaction among teammates inside a code development environment. Its creator, Nathan Sobo, envisions a revolutionary tool that will impact social coding collaboration similar to how GitHub has revolutionized file system snapshots. In this article, we explore the backend development of Zed and Nathan’s insights on creating a performance-optimized system in Rust.
Edited transcription
Nathan Sobo is the creator of the Atom editor and software development framework Electron. His experience creating these two popular apps is proving handy for his current project, Zed, a collaborative code editor “that focuses on performance, clean design, and being multiplayer.” With pair programming in mind, the idea behind Zed’s development is to build a tool that enhances real-time collaboration in code design and makes “it really easy to interact with your teammates directly inside your code authoring environment.”
Having practiced pair programming since the beginning of his career, Nathan understands that in collaborative coding “there’s so much more interaction that potentially needs to happen than just discussing some changes that I want to introduce.” To him, collaboration is narrowed by the ways of working asynchronously. Instead, he proposes to ask about the code even before getting started or getting immediate assistance when encountering an issue, so collaboration takes place “from when you’re thinking about implementing something all the way through implementing it and also when you’re done and you want to introduce those changes.”
As such, despite Nathan isn’t against working alone —and admits he doesn’t pair-program as much as before— he believes that “a little bit of synchronous interaction just really goes a long way and spreading knowledge about the code through the code base, just cross-fertilizing ideas,” has a positive effect in trusting your coworkers and solving issues together.
The backend development of Zed and why performance is critical
Nathan asserts that performance is the most important factor to guarantee Zed’s adoption. Hence, while at the beginning they thought of using Rust just for the application backend and using Electron for rendering web content, Zed’s team observed that Electron’s resource footprint was diminishing the performance they were gaining at the core.
The solution was integrating graphics rendering in the core application through shader code (code run by the GPU) written in a metal shader language, which allows this integration. The Zed team even built their own UI toolkit for the app; the OS only renders the window buttons. As Nathan explains, since Zed is completely written in Rust, it can “redraw the entire window on the GPU on every update, just like a video game”, resulting in an “extremely low latency.” At the same time, Zed was integrated with the macOS event loop, so they didn’t have to write their own render loop.
Achieving network collaboration
In Zed, the server and clients operate as a single system that spans the network boundary. Zed users can add other users as contacts by their GitHub usernames and invite them to participate in their projects. After that, a web socket connection is created to the Zed server, and the other user’s remote procedure call (RPC) can see requests through the server to understand the paths in the project. When the other user opens a file, they will also use RPC to send an open request.
Additionally, Zed uses a conflict-free replicated data type to represent data in the buffer. When users edit files, they apply their edits to their local copy and exchange operations to converge on the same content. Zed structures data in such a way that a little bit of latency is acceptable for some actions, like opening a file, but not for editing, which requires real-time exchange of data.
Testing edge cases
For testing in Zed, Nathan applied much of what he had learned in past projects. Specifically, the fact that unit tests will create a solid product, but will only get you so far. As a large number of people begin to use the application, they will inevitably encounter bugs in unlikely scenarios that were not previously tested.
Nathan finds that “the only way to find bugs is just to stress test our data structures and our software” with fuzz testing, in which a random number generator bombards “data structures with every possible interaction path.” Nathan and the rest of the team used this approach to test the program network components and found lots of unforeseeable bugs with it.
The solution to address these bugs was writing a custom executor that allowed them to integrate effectively with the macOS event loop. This custom executor was only used for tests and was designed to run non-deterministic, concurrency-laden integration tests in a repeatedly deterministic way. They seeded the executor with a random number generator and simulated all the network interactions, enqueuing all the places where IO might introduce asynchrony onto the deterministic executor.
In this way, explains Nathan, as he and his teammates encountered 0.1% of cases where things failed, they could feed the same seed back into the random number generator and run the test repeatedly until they found the bug. They also ensured that their tests ran the same set of sequences every time to avoid the problem of flaky tests.
Lastly, Nathan acknowledges the need to limit the number of combinations testing tries. In his experience, once complex tests with a great deal of randomization have been run tens of thousands of times and given green after a few hours have passed, then you can trust that it will continue to pass the test.
The future of Zed
Zed is still in its early stages and has a long roadmap of features ahead, being Copilot integration and language support the most demanded. Nathan has in mind a modality of Zed that would work as some sort of mob programming of sorts in the way of an interactive Twitch stream, where you can code and the audience can participate. In this same regard, Zed could also have a microphone to allow people to chat. Also, Nathan has in mind a working hours feature in which you can indicate when you want to chat and when you don’t and want to focus on your work alone.
Currently, Zed does not offer support for add-ons. While it has been asked, Nathan believes it is important first and foremost to ensure the quality of the product. While he believes that Zed will support add-ons eventually, he also understands that once you rely on third parties, you lose control in terms of quality assurance: “Right now inside of Zed, if something isn’t making sense, I can just change it. And as soon as you have other people building on top of what you’ve built, you can’t do that anymore.”
The bottom line
Download Zed open beta and try it for yourself. You can help developers by sharing your feedback: either through a feedback tool in the editor or in the GitHub repository. Currently, Zed only supports macOS. However, there are open discussions for Linux, web, and Windows support. Visit zed.dev to learn more about the app and the team behind it.
You can follow Nathan Sobo on Twitter and GitHub.
