mikaylamaki

That is a different project :D

Here's our overall pitch: https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...

We’ve been growing and have had to scale authentication beyond what our original collab server could handle. Not many people are using collab yet, we’re prioritizing non-collaborative features (like our recent Windows release), and we’re planning on rebuilding all of this on top of DeltaDB. Fundamentally, it just fell through the cracks.

Self hosting will be a vital feature for users and enterprises though, we’re planning on revisiting it once we have a few more features settled :D

Unfortunately, we no longer support self hosting. We're planning on reintroducing it once we've polished the single player experience a bit more :)

People have been doing collaborative text editing since the 60s actually! See, The Mother Of All Demos[0], referenced in our first blog post[1] :D

I'd say CRDTs are also a big change. CRDTs make live collaboration much more robust for all parties involved, and they only started to reach maturity in the mid-late 2010s

[0] https://en.wikipedia.org/wiki/The_Mother_of_All_Demos

[1] https://zed.dev/blog/crdts

It’s quite the experience

Actually, Anthropic built that integration themselves.

Yeah! It's a good sign that this idea is in the air and the industry is moving towards it. Excited to get rid of all the magic wands everywhere :D

FWIW, we plan to sell "enterprise" builds of Zed with SSO, centralized plugin repositories, business-hosted infra, etc. etc. The sorts of features developers don't care about but businesses do. To do that, we have to be able to re-license the codebase and apply these changes. We have a lot of other ideas for business sustainability but the core, offline code editing experience will always be freely available and open source though :)

The code gen example given later sounds an awful lot like what AWS built with Kiro[1] and it's spec feature. This article is kinda like the theory behind the practice in that IDE. I wish the tools described existed instead of all these magic wands

[1] https://kiro.dev/blog/introducing-kiro/

We do! Sorry we missed your feedback.

Agreed. The predict edit feature needs to be actively enabled before it'll do anything. And once it's enabled, it won't send up your private keys or environment variables. If their filename matches a glob in this list, or a list you configure.

> a private key or API key could get sent, right?

You can disable this feature on a per-file basis, here’s the relevant setting: https://github.com/zed-industries/zed/blob/39c9b1f170cd640cd...

Sorry you had this experience with Zed. We've seen a few reports of issues with our python integration (https://github.com/zed-industries/zed/issues/23170, https://github.com/zed-industries/zed/issues/22426), and we'll be taking a look at these next week. Please do a file an issue for performance problems like this, it's a bug if Zed isn't fast for your use case :)

At Zed, we use our native collaboration to make sure we get a lot of synchronous time together. We also use it to do design review as we're coding a feature, letting us skip code review all together!

We'd appreciate the issue and discussion! We've been aware of contrast issues for some time, and I personally have been thinking about switching our color representation from HSL to OKLCH to give us more traction on these problems. But I've been working on Linux and am not a designer, so I haven't had the chance :D

We have a flatpak build! It's not on flathub yet though :)

https://github.com/zed-industries/zed/blob/main/docs/src/dev...

We have a few words on this in our troubleshooting guide:

https://zed.dev/docs/linux#troubleshooting

Let us know if that doesn't fix it!

Check out our troubleshooting page, you might not be utilizing the GPU!

https://zed.dev/docs/linux#troubleshooting

If that doesn't work for you, please file an issue, and let us know whether you're using Wayland or X11 :)

We call them 'multibuffers' :D

https://zed.dev/features#multi-buffers

As a Zed developer, our killer feature is the parallel programming that our software enables. It's like pairing without the terrible parts.

After we finished prepping this linux launch, we've started work on making this situation better. Follow along here: https://github.com/zed-industries/zed/pull/14034

That does seem more usable for this use case. I'll keep it in mind, thank you!

Roughly yes, though I'd caveat it with the specific application of the GPU: simple, 2D, UI elements. We've already built an abstraction that allows us to fluently build up a design, and then burn it down into a collection of rectangles, paths, images, and such. We're not dealing with particle effects, lighting, 3D models, or anything else that game engines need to consider. As such, it's a lot lower cost for us to use something like Vulkan or DX12 directly. And, in fact, that was the backup plan if we didn't find something like Blade that we where happy with.

Simply put: historical artifact and we want to own the stack. Zed was first created when these abstractions where a lot younger, and a text editor needs certain features, like IME support, that weren't as common back then. Further, owning the stack we're built on gives us the flexibility to change the framework whenever and however we want, which we value more than the additional work it takes to re-implement things ourselves.

Right now: mixed. We provide both user defined themes and theme overrides that let people color-correct things as they need, we have a strong cultural focus on keyboard accessibility for all UI elements, you can increase or decrease the font size in the editor and the UI, and we have strong support for IME on macOS and will be extending that to Windows and Linux.

However, our accessibility to screen readers is non-existent. I have ambitions to incorporate AccessKit but it's a bit of a project due to the lack of a clear guide on how to implement it. That said, I already made some progress based on the old egui PR and we should have all the pieces we need once I have time to actually do it.

We also lack any way to tab through our UI elements to select each piece in turn. This one I have yet to do any thinking on, particularly as the tab key already does a lot of work in a code editor. I'm sure there's prior art here, I just haven't looked at it yet.

So, piecemeal and insufficient for many cases, usable for some others. I'm very interested in improving this but we still have a lot to do.

Unfortunately, the renderer is only one step in supporting an alternative platform. Even if we could have used Vulkan on every platform, the windowing APIs are completely different and those do most of the things we like our code editors to support, like typing.

Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long term platform goals (Linux, Windows, and the web though via WebGL). So far, it's been running flawlessly, and it's been everything else that's the hard part!

We use them every day at Zed for pair programming, we're rather fond of the features :D

Yep! That's how we did it, with the heavy lifting done by the delightfully named "Aperture Science Handheld Portal Device" crate: https://crates.io/crates/ashpd

Yes! In fact, that's one of our planned revenue sources, once we've fleshed things out :D :D