We think there's a better way to write code, and it starts with the following assumptions:
When you move the cursor or type a character, you should see pixels on the next refresh of your display—every time. Even sub-perceptual pauses add up over the course of a day to create unnecessary stress.
Joyful coding starts with an editor that stays out of your way.
Pull requests have their place, but sometimes you just want to code together. It's more fun than code review, builds trust between colleagues, and it's one of the best ways to distribute knowledge through a team. But it has to be easy.
If you want someone's perspective on a piece of code, it should be as easy as sending a message to pull them into your working copy and start coding.
If you want to talk about code on GitHub you have to commit and push it first, and pasting code into a chat application sucks.
By treating keystrokes as the fundamental unit of change and integrating chat into the editor, we can make it easy to have a conversation about any line of code in any working copy–whether it was committed last year or just typed ten seconds ago.
If you're living in a tool for hours every day, you want it to disappear. Every pixel must carry its weight, and the software you're creating should always be the focus. So we constantly ask ourselves how we can maximize signal and minimize noise.
Do we need an icon? Do we need a gradient? We all want to achieve mastery. Our goal is to find the most efficient way to accomplish each coding task and make it accessible. We will never dumb things down.
———
We're looking to add another engineer to the team. Want to help us build the future? Join us.
———
Rust offers expressivity and developer productivity rivaling languages that depend on a VM, while simultaneously offering the control required to fully utilize the underlying hardware.
Rust's unique ownership model is a challenge at the beginning, but once you internalize it, you can write extremely efficient multi-core code without fear of invoking undefined behavior.
It also makes it straightforward to call directly into the C-based APIs of the operating system. Rust makes it possible for a small team to build a complex product quickly, and Zed wouldn't have been possible without it.
In the past, to write software with this performant you would need to use C++. Rust, for the first time, enables us to write software at that level as a very small team.
We originally planned to use Electron as a convenient means of delivering a cross-platform GUI for Zed, while building the core of the application in Rust. But at every turn, we found that web technology was the bottleneck in achieving amazing performance. Finally, we decided to take full control and simply build a GPU-powered UI framework that met our needs.
We call it GPUI.We took a lot of inspiration from Mozilla's Webrender project. The key insight was that modern graphics hardware can render complex 3D graphics at high frame rates, so why not use it to render relatively simple 2D user interfaces with an immediate mode architecture?
Rust's ownership model required us to rethink much of what we learned in other UI programming paradigms, but the result is a framework that's productive to use and remarkably easy to reason about.
It's liberating to control every pixel, and it's a rush to push those pixels at lightning speed.
Real-time collaborative editing presents the illusion that multiple people are editing the same buffer. In reality, each collaborator maintains their own personal replica of the buffer to which they can apply local edits immediately without network latency.
After being applied locally, edits are transmitted to collaborators over the network, whose copies may have also changed in the meantime. This means that as participants edit together, their replicas continuously diverge and reconverge. Turns out this is a tricky problem.
To solve it, we're using conflict-free replicated data types, which have emerged in the last decade as a general framework for achieving eventual consistency in a variety of circumstances.
Making Zed's buffers CRDTs allows for collaborative editing, but it also helps us reason about concurrent change so that we can push work into background threads and keep the UI thread responsive.
We plan to integrate with the Language Server Protocol to support advanced IDE features, but we also think it's important for a code editor to have a rich, native understanding of syntax.
That's why we built Tree-sitter, a fast, general, incremental parsing library that can provide Zed with syntax trees for over 50 languages. Tree-sitter already powers production functionality on GitHub, and we'll use it to deliver syntactically-precise syntax highlighting, tree-based selection and cursor navigation, robust auto-indent support, symbolic navigation, and more.
———
Excited about what we are building? Sign up for updates to follow along in our development process.
