GPUI has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.
Hey, we're actively working to get in touch with a new lawyer to help us do a better job with this. I agree this isn't cool. I was rushed to get the launch out and didn't review the terms carefully enough. We will try to do better going forward. Our goal is to be respectful.
The former Atom team and some new friends are building a new editor over at https://zed.dev. We're using our own Rust-based UI framework instead of Electron so it's really fast, and real-time collaboration is baked into the core.
Hey, thanks for the heads up. I screwed it up once and duplicated it through everything. Going to fix it. He was too important to insult by misspelling his name.
We’ve gone to great lengths to abstract out the platform dependencies. Adding a platform right now doesn’t teach us enough for it to be worth it just yet, but we’re seriously planning for it.
I have always found CRDTs a lot easier to wrap my brain around. Agreed with Joseph that optimizing them is non-trivial. In Teletype for Atom, we indexed fragments in splay trees, and each text fragment was actually a member of two splay trees at the same time: one for the full document, another for the pieces of the original insertion as they'd been split apart. We would find the insertion fragment in the insertion tree, then walk parent pointers in the document tree to locate it. In Zed, we have two trees, but can't do this double embedding because we use persistent data structures where parent pointers are not an option. So we instead have insertion trees that map subslices of inserted text to fragment ordered identifiers, which we use for lookup in the main document B-tree. These fragment identifiers were themselves inspired by another CRDT paper called Logoot, but we don't actually send them over the wire.
I've been interested in them since the early days of Atom, but it's just taken a while for me to develop as an engineer and build a system around the theory that puts them to practical use.
Earlier this year Keith Simmons, the author of Neovide (https://github.com/neovide/neovide), joined our team. He's been working on Vim bindings and paying a lot of attention to getting it right. As you probably know there's a lot of surface area, so this will take time.
When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point.
Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
We have graphics, but I could see a mode where you `scp` a headless moon lander version of Zed up to a remote server to do remote development. VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.