nathansobo

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.

Wow Brian, nice to hear from you. Thanks very much for your words! I remember you setting a new standard of speed for me when we worked together!

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.

We honestly don’t solve it yet, but haven’t found it that big of an issue in practice. Would be curious to see the best resource on it.

Thanks very much!

We embeded a lot of videos for animated diagrams. I think we need to disable autoplay, at least on mobile.

We're quite happy with them. Why do you find them annoying?

Definitely a priority.

"Real real fast"

We're pure Rust and hopefully faster. But yeah, plenty of competition in the space!

Our goal is to build something substantially better than VS Code.

We plan to start blogging about this pretty soon.

This would only be for the web. Right now we're macOS only and target Metal.

We just wanted to be pure Rust and have complete control.

Thanks very much!

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.

Here's a demo from a talk a give not too long ago:

https://youtu.be/wXT73bBr83s?list=PL3TSF5whlprXqwYNIM0X8mBzu...

We do have plans. Stay tuned!

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.

We plan to compile to WebAssembly that writes pixels to a WebGL canvas.

Fabulous point. Always good to have solid contingency plans.

Sure, cross-platform UI that's on the metal is a more accurate description.