Zed: High-performance AI Code Editor
446 comments
·May 7, 2025isaacimagine
porsager
I wish they would have stayed with the collaborative part a bit longer. Once the AI wave hit it feels abandoned with various bugs and hard to reproduce issues. I am a full time zed user converting from sublime only due to the collaborative features, but by now we don't even use the collaborative features anymore because it's unreliable (broken connections, sounds, overwriting changes, weird history/undo behavior), so will probably go back to sublime again. Note that all of us are sitting on fiber connections, so I don't believe the issues are network related.
I've been trying to be active, create issues, help in any way I can, but the focus on AI tells me Zed is no longer an editor for me.
maxbrunsfeld
Yeah, we plan to revisit the collaboration features; it was painful but we decided we needed to pause work on it while we built out some more highly-requested functionality. We still have big plans for improving team collaboration!
CuriousRose
It would be interesting to (optionally) make the AI agent more like an additional collaborative user, sharing the chat between users, allowing collaborative edits to prompts, etc.
giancarlostoro
Not sure what your budget looks like, but maybe its time to look for a new developer if its feasible? So you don't neglect a feature that's already in production and broken.
echelon
It's absolutely remarkable that these folks are writing this from scratch in Rust. That'll be a long-term killer feature for the editor.
Do you think GPL3 will serve as an impediment to their revenue or future venture fundraising? I assume not, since Cursor and Windsurf were forks of MIT-licensed VS Code. And both of them are entirely dependent on Microsoft's goodwill to continue developing VS Code in the open.
Tangentially, do you think this model of "tool" + "curated model aggregator" + "open source" would be useful for other, non-developer fields? Would an AI art tool with sculpting and drawing benefit from being open source? I've talked with VCs that love open developer tools and they hate on the idea of open creative tools for designers, illustrators, filmmakers, and other creatives. I don't quite get it, because Blender and Krita have millions of users. Comfy is kind of in that space, it's just not very user-friendly.
dotancohen
> entirely dependent on Microsoft's goodwill to continue developing VS Code in the open.
To be clear, by "the user" I'm referring to the Cursor devs. This is the terminology of many F/OSS licenses.
null
maxbrunsfeld
Isaac, that email that you sent to us (long after your internship ended) when Wasmtime first landed support for the WASM Component model was actually very helpful! We were considering going down the path of embedding V8 and doing JS extensions. I'm really glad we ended up going all in on Wasmtime and components; it's an awesome technology.
isaacimagine
Yes, Wasm components rock! I'm amazed to see how far you've taken Wasm and run with it. I'm at a new email address now, apologies if I've missed any mail. We should catch up sometime; I'll be in SF this summer, I might also visit a friend in Fort Collins, CO. (Throwing distance from Boulder :P)
bschwindHN
Hey Isaac! I was intrigued by the way Zed added extensions, and I think it turned out great! I ended up taking that pattern of WASM, WIT, and Rust traits to add interactive hot reloading in a few projects. It feels like it has a strong future in gamedev where you could load and execute untrusted user mods without having all your players getting hacked left and right.
Good luck on finals!
isaacimagine
Thank you Brian! I miss tonari, I hope you're well. Game mods seem like a great fit for Wasm! I'm excited about Wasm GC, etc., because it means you can use e.g. a lightweight scripting language like Lua to sketch a mod, with the option of using something heavier if you need that performance.
pimeys
Hey! I was reading your extensions code a lot. The backwards compatibility is done in a smart way. Several layers of wit and the editor makes the choice based on wasm headers which one to choose.
I learned something from that code, cool stuff!
One question: how do you handle cutting a new breaking change in wit? Does it take a lot of time to deal with all the boilerplate when you copy things around?
lordofgibbons
I really want to move off VS Code and start using Zed, but unfortunately the text is always extremely blurry. It's just unusable.
I check back on the GitHub issue every few months and it just has more votes and more supportive comments, but no acknowledgement.
Hopefully someone can rescue us from the sluggish VS Code.
https://github.com/zed-industries/zed/issues/7992
I have a 1440p monitor and seeing this issue.
AndrewDucker
Several replies saying that the issue is with the monitor. When the issue has an example showing Zed next to VS Code, and you can see that Zed is much blurrier: https://github.com/zed-industries/zed/assets/5507503/9883d38...
turnsout
Looks like you're trying to turn off antialiasing entirely, which is a bit niche
sapiogram
Thank you, I bring this up in every Zed thread on the internet, hopefully the devs will eventually fix it. Until they do, Zed is simply unusable on regular-DPI displays, at least in light mode. See these screenshots:
Example Zed screenshot, using "Ayu Light": https://i.ibb.co/Nr8SjvR/Screenshot-from-2024-07-28-13-11-10...
Same code in VS Code: https://i.ibb.co/YZfPXvZ/Screenshot-from-2024-07-28-13-13-41...
nyanpasu64
I think it's a combination of using a Zed theme with insufficiently high text contrast, missing subpixel font rendering in Zed, and possibly more gamma correction and less stem darkening than you're used to.
WD-42
Zed defaults to a font weight a little thin for my taste, increase it and it will probably solve your issue. I don’t see anything really wrong with the first screenshot, might just be a matter of what you are used to.
Yizahi
I'm wildly guessing here, but I remember that at some point in time macos had (and maybe has) this feature enabled by default which artificially makes pseudo-bold font out of regular font. That's why some websites have very thin and unreadable fonts, because they were tested only on macos. Maybe it's the same issue here? Looks kinda similar.
Setting on macos was called "use font smoothing when available".
sapiogram
It's the exact same on Linux.
karunamurti
Use the same font and increase the font weight.
Geee
I don't see the difference except that the font is thinner in the Zed screenshot. Try with same font weight and color scheme.
dotancohen
From the Zed homepage:
> The entire Zed code editor is open source under GPL version 3, and scratch-built in Rust all the way down to handcrafted GPU shaders and OS graphics API calls.
In my opinion, this type of graphics work is not the core functionality of a text editor, same has been solved already in libraries. There is no reason to reinvent that wheel... Or if there is then please mention why.
hamandcheese
> In my opinion, this type of graphics work is not the core functionality of a text editor, same has been solved already in libraries.
In a world full of electron based apps, I appreciate anyone who dares to do things differently.
JonGretarB
Most likely there were no ready libraries when they started. Even now there are very few that can be called stable. And even then many of them are HTML based. So if you are going to spend that much time developing GUI from scratch you might as well make it your own library and get full control.
naikrovek
shrink the zed window by one pixel horizontally and one pixel vertically. there's a video on that issue page which shows resizing making the font go in and out of focus, and that tells me that there's something dividing the window height and width by 2 and starting the font rendering there. if you divide by 2 and you get .5, you'll see the blurriness. if you make the window 1 pixel wider you won't get x.5 anymore, you'll get a whole number.
try it and see. i bet that helps/fixes at least some of you suffering from this.
nyanpasu64
This smells like a fractional DPI scaling issue.
naikrovek
It can happen at any scaling, depending on how you anchor controls in the application window.
A text area anchored correctly to the top and left of the window would absolutely not move no matter how tall or wide the window is, and no display scaling setting would impact that.
barrenko
Not sure if it's related, but I've built Zed from source to try on Windows (I haven't tried it on other platforms), and it does not look good sadly, it's also quite a bit "uncrisp" or something - I don't really have the words to describe.
testycool
Well said. "uncrisp" is how I'd describe it as well.
EnPissant
I tried zed and experienced the same thing (also 1440p), so now I don't use it.
I have the same issue with macOS in general, and I don't understand how anyone can use it on a normal DPI monitor.
I'm guessing zed implemented their own text rendering without either hinting or subpixel rendering or both.
ivanche
MacOS looks nice on either ~110dpi or ~220dpi monitor. Anything else and you get a blurry picture.
freehorse
Everything, including zed, looks fine in the 95dpi (1080p 23") monitor I use right now with my macbook.
I have had similar blurring problems with a certain monitor (1920x1200 27"), which was resolved with changing some sharpening settings in the monitor itself. Strangely, that setting did not look well at my colleague's macbook, who was also often using that monitor, while the original settings looked fine, so we had to change the settings back and forth every time the other person had to use it. I do not think I was using zed at the time, other apps had that issue.
EnPissant
While "nice" is subjective, macOS is objectively blurrier on a ~110dpi monitor than on Windows or Linux.
This is because macOS does not support subpixel rendering or hinting.
johnnypangs
Shout out to Better Display, I find it helps with Lo DPI blurriness in general on macOS
jojohohanon
Does your monitor have a nonstandard rgb pattern? If zed is trying to do its own subpixel rendering then getting the pattern wrong is going to mess up your results.
(Or are you using it in vertical orientation?)
ammmir
I was using Zed up until a few months ago. I got fed up with the entire AI panel being an editable area, so sometimes I ended up clobbering it. I switched to Cursor, but now I don't "trust" the the editor and its undo stack, I've lost code as a result of it, particularly when you're in mid-review of an agentic edit, but decide to edit the edit. The undo/redo gets difficult to track, I wish there was some heirarchical tree view of history.
The restore checkpoint/redo is too linear for my lizard brain. Am I wrong to want a tree-based agentic IDE? Why has nobody built it?
senko
> I got fed up with the entire AI panel being an editable area, so sometimes I ended up clobbering it.
They fixed that with the new agent panel, which now works more like the other AI sidebars.
I was (mildly) annoyed by that too. The new UI still has rough edges but I like the change.
freehorse
Interesting. I actually like the editable format of the chat interface because it allows fixing small stuff on the fly (instead of having to talk about it with the model) and de-cluttering the chat after a few back and forths make it a mess (instead of having to start anew), which makes the context window smaller and less confusing to the model, esp for local ones. Also, the editable form makes more sense to me, and it feels more natural and simple to interact with an LLM assistant with it.
dtkav
Yes! Editing the whole buffer is a major feature because the more you keep around failed attempts and trash the dumber the model gets (and more expensive).
If you're working on stuff like marketing websites that are well represented in the model dataset then things will just fly, but if you're building something that is more niche it can be super important to tune the context -- in some cases this is the differentiating feature between being able to use AI assistance at all (otherwise the failure rate just goes to 100%).
koito17
> I actually like the editable format of the chat interface because it allows fixing small stuff on the fly
Fully agreed. This was the killer feature of Zed (and locally-hosted LLMs). Delete all tokens after the first mistake spotted in generated code. Then correct the mistake and re-run the model. This greatly improved code generation in my experience. I am not sure if cloud-based LLMs even allow modifying assistant output (I would assume not since it becomes a trivial way to bypass safety mechanisms).
ntonozzi
The old panel still exists, they call it a text thread.
cedws
I’m on the opposite end, I hate the new panel. It’s less space efficient, slash commands are gone, and I can’t figure out how to clear the chat.
cies
All vims and emacses can have undo-tree (as a plugin iirc). Many devs use it.
Vote/read-up here for the feature on Zed: https://github.com/zed-industries/zed/issues/17455
And here on VSCode: https://github.com/microsoft/vscode/issues/20889
tgtweak
Been using cline and their snapshot/rewind/remove context (even out-of-order) features are really shining especially with larger projects and larger features+changes becoming more commonplace with stronger LLMs.
I would recommend you check it out if you've been frustrated by the other options out there - I've been very happy with it. I'm fairly sure you can't have git-like dag trees, nor do I think that would be particularly useful for AI based workflow - you'd have to delegate rebasing and merge conflict resolution to the agent itself... lots of potential for disaster there, at least for now.
mrorigo
omg. "the entire AI panel being an editable area" is the KILLER feature for me! I have complete control, use my vim keys, switch models at will and life is awesome.
What I don't like in the last update is that they removed the multi-tabs in the assistant. Previously I could have multiple conversations going and switch easily, but now I can only do one thing at a time :(
Haven't tried the assistant2 much, mostly because I'm so comfy with my current setup
conartist6
Worry not, for it is being built.
You will not catch me using the words "agentic IDE" to describe what I'm doing because its primary purpose isn't to be used by AI any more than the primary purpose of a car is to drive itself.
But yes, what I am doing is creating an IDE where the primary integration surface for humans, scripts, and AIs is not the 2D text buffer, but the embedded tree structure of the code. Zed almost gets there and it's maddening to me that they don't embrace it fully. I think once I show them what the stakes of the game are they have the engineering talent to catch up.
The main reason it hasn't been done is that we're still all basically writing code on paper. All of the most modern tools that people are using, they're still basically just digitizations of punchcard programming. If you dig down through all the layers of abstractions at the very bottom is line and column, that telltale hint of paper's two-dimensionality. And because line and column get baked into every integration surface, the limitations of IDEs are the limitations of paper. When you frame the task of programming as "write a huge amount of text out on paper" it's no wonder that people turn to LLMs to do it.
For the integration layer using the tree as the primary means you get to stop worrying about a valid tree layer blinking into and out of existence constantly, which is conceptually what happens when someone types code syntax in left to right. They put an opening brace in, then later a closing brace. In between a valid tree representation has ceased to exist.
pierrec
Representing undo/redo history as a tree is quite different from representing the code structure as a tree. On the one hand I'm surprised no one seems to care that a response has nothing to do with the question... on the other hand, these AI tooling threads are always full of people talking right past each other and being very excited about it, so I guess it fits.
conartist6
They certainly can be quite different things and in all current systems I know of the two are unrelated, but in my system they are one and the same.
That's possible because the source of truth for the IDE's state is an immutable concrete syntax tree. It can be immutable without ruining our costs because it has btree amortization built into it. So basically you can always construct a new tree with some changes by reusing most of the nodes from an old tree. A version history would simply be a stack of these tree references.
gnrlst
I've very interested in this, and completely agree we are still trying to evolve the horse carriage without realizing we can move away from it.
How can I follow up on what you're building? Would you be open to having a chat? I've found your github, but let me know how if there's a better way to contact you.
conartist6
The BABLR Discord is the spot, though I'm also happy to take emails: https://discord.gg/NfMNyYN6cX (and yes I'm happy to chat!)
divan
Meanwhile I'm checking Helix editor every 6 month to see if authors became any less hostile to the idea of thinking about considering of starting thinking about potentially adding copilot support.
master-lincoln
Why should an open source editor support some single commercial product API in their core? Why copilot and not another product? It's completely reasonable to me that this should be a third party plugin or that they should wait for some standard that supports many products.
lemontheme
As @adriangalilea recently aptly wrote in Helix's 2nd-longest discussion thread (#4037):
> For the nth time, it's about enabling inline suggestions and letting anything, either LSP or Extensions use it, then you don't have to guess what the coolest LLM is, you just have a generic useful interface for LLM's or anything else to use.
An argument I would agree with is that it's unreasonable to expect Helix's maintainers to volunteer their time toward building and maintaining functionality they don't personally care about.
dcre
As I say in my comment, they may even care about it but not have time to churn while best practices are figured out.
dcre
It's not about it being locked to a commercial product — whatever they built would be provider-agnostic. My understanding is the decision is more about not wanting to build things into core that are evolving so quickly and not wanting to rely on experimental LSP features (though I think inline completions are becoming standard soon[1]). Zed itself is perfect evidence of that -- they built an AI integration and then basically had to throw it away and rebuild it because the consensus best practice design changed. The Helix maintainers don't have time for that kind of churn and aren't trying to keep up with the hype cycle. When the plugin system is ready people will be able to choose their preferred implementation, and maybe eventually some aspects of it will make it into core.
[1]: https://microsoft.github.io/language-server-protocol/specifi...
null
lemontheme
Interestingly enough, this is exactly why I've started using Zed – while simultaneously eagerly waiting for Helix PR #8675 (Steel plugin system) to get merged. It's not far off, but then again, many Helix PRs seem that way, only to stay in limbo for months if not years.
These last two months I've been trialing both Neovim and Zed alongside Helix. I know I should probably just use Neovim since, once set up properly, it can do anything and everything. But configuring it has brought little joy. And once set up to do the same as Helix out of the box, it's noticeably slower.
Zed is the first editor I've tried that actually feels as fast as Helix while also offering AI tooling. I like how integrated everything is. The inline assistant uses context from the chat assistant. Code blocks are easy to copy from the chat panel to a buffer. The changes made by the coding agent can be individually reviewed and accepted or rejected. It's a lot of small details done right that add up to a tool that I'm genuinely becoming confident about using.
Also, there's a Helix keymap, although it doesn't seem as complete as the Vim keymap, which is what I've been using.
Still, I hope there will come a time when Helix users can have more than just Helix + Aider, because I prefer my editor inside a terminal (Helix) rather than my terminal inside an editor (Zed).
undo-k
The authors don’t seem hostile at all. They’re firmly against putting work into a feature they don’t care for but welcome pro-AI users to make it happen. For some reason the latter group hasn’t seemed to accomplish it.
nba456_
This is exactly why I bounced off Helix a while ago. No copilot and endless bikeshedding for plugin development.
eikenberry
The bikeshedding has long past. They've been working on the implementation now for some time.
Buttons840
Helix is working on a plugin system that will hopefully allow for copilot (or whatever other product) use.
Also, the Helix way, thus far, has been to build a LSP for all the things, so I guess you'd make a copilot LSP (I be there already is one).
lemontheme
Unless something's changed, every AI-backed language server I've tried in Helix suffers from the same limitation when it comes to completions: Suggestions aren't shown until the last language server has responded or timed-out. Your slowest language server determines how long you'll be waiting.
The only project I know of that recognizes this is https://github.com/SilasMarvin/lsp-ai, which pivoted away from completions to chat interactions via code actions.
unshavedyak
I feel like an LSP is very insufficient for the ideal UX of AI integrations. LSP would be fine for AI autocompletes of course, but i think we want a custom UX that we don't quite yet know. Eg what Zed offers here seems useful. I also really like what Claude Code does.
I don't know the LSP spec well enough to know if these sort of complex interactions would work with it, but it seems super out of scope for it imo.
level87
I love Helix, not fussed about this at all, happy to use a robust editor that doesn't have hundreds of plugins barely holding it together.
benrutter
This rings so true for me! Helix is beautiful and works fantastic, I'm pretty happy not having AI integrated into my editor so Helix is basically exactly as I want without any extras I don't!
eikenberry
This seems more in scope of those same people who want to make their editor into an IDE. And just like most other things, the editor is a poor integration point for AI. The shell and inter-process communications are the gold standard for integration and are where the best integrations emerging from. Things that work with your editor instead of trying to replace it. Aider being the best example I've seen so far... though I'd love to hear about others.
bigstrat2003
That honestly makes me want to check out Helix. I'm so tired of seeing AI get forced into everything that "we won't add that" is a feature to me.
divan
I can understand that, and it's great if it fits your needs. It's annoying when apps that just have to do one thing and do it well instead are focusing on hype features. My recent rant is about Warp terminal that has a "different font size for different tabs" issue open for years, but silently integrated all sorts of AI into the terminal.
And yet, it's hard to ignore the fact that coding practices are undergoing a one-in-a-generation shift, and experienced programmers are benefiting most from it. Many of us had to ditch the comfort of terminal editors and switch to Microsoft's VSCode clones just to have these new incredible powers and productivity boosts.
Having AI code assistants built into the fast terminal editor sounds like a dream. And editors like Helix could totally deliver here if the authors were a bit more open to the idea.
volkk
Zed is exactly how software should be made. Granted, I don't agree with all of their UX decisions (i think the AI panel is really bad compared to Cursor's), but good lord is the thing fast. These guys are the real deal. They built a rendering system (GPUI) in Rust before building Zed on top of it, and so it is one of the fastest (if not the fastest) pieces of software that resides on my computer. I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it, because the other Rust GUI libraries/frameworks aren't great.
edit: they updated the AI panel! looking good!
unshavedyak
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
Man, so true. I tried this out a while back and it was pretty miserable to find docs, apis, etc.
IIRC they even practice a lot of bulk reexports and glob imports and so it was super difficult to find where the hell things come from, and thus find docs/source to understand how to use something or achieve something.
Super frustrating because the UI of Zed was so damn good. I wanted to replicate hah.
volkk
part of me wants to dedicate time to making something with it and then creating examples/PRs -- but it's too unstable given how fast they're moving for now IMO. if anyone from Zed team can chime in and confirm, that'd be awesome.
rtfeldman
> i think the AI panel is really bad compared to Cursor's
Have you had a chance to try the new panel? (The OP is announcing its launch today!)
input_sh
It was available in their preview release for about a month: https://zed.dev/releases/preview
The annoncement is about it reaching prod release, but they emailed people to try it out in the preview version.
volkk
i have and it's more of the same (unless i'm missing something). the fact that the entire thing is editable is weird to me. i really think they should just clone cursor's in this one case because they really nailed the UX with the checkpoint restoration
edit: yes i missed something. i see the new feature. hell yeah!
humlex
Its the opposite to me. I really liked that the AI panel was a fully featured text editor buffer like any other. The new agent panel makes it too much like "the rest" haha. I guess I'll get used to it over time. The important thing is that we finally have agentic editing which is extremely powerful ofc.
rtfeldman
Ah, that's still the old one - the whole thing is no longer editable in the new one we launched today. (You can still access the old one, but the new one is the default as of today.)
Check out the video in the blog post to see the new one in action!
terhechte
In the new agent panel not everything is editable. Maybe give it another try.
duped
Is it only fast on MacOS? I tried it on Linux and it was unusably slow. Seconds per frame instead of frames per second.
signorovitch
I’ve been using Zed a few months on my fedora laptop (thinkpad x230) and haven’t had any performance issues. Definitely faster than any other graphical editor I’ve used. Perhaps a driver issue would be slowing it down?
duped
Maybe, but no other application or editor has this problem. If all other apps work but Zed doesn't then it sounds like a Zed has an issue.
EDIT: just gave it a shot and I get "unsupported GPU" as an error, informing me that my GPU needs Vulkan support.
Their detection must be wrong because this is not true. And like I said, other applications don't have this problem.
dtkav
I ran into the same issue (software rendering), pushed through to get it working, and it was worth it. It is extremely fast.
I'm on PopOS and the issue ended up being DRI_PRIME.
Might be worth trying `DRI_PRIME=0 zed`.
curt15
Linux user here. I find Zed lightning fast compared to VSCode.
cess11
I'm under Debian and i3wm/X11, sometimes it does some stuff that blocks input for a while so I can't drive the window manager until its done.
At least it did a month or so ago, and at that time I couldn't figure out a practical use for the LLM-integration either so I kind of just went back to dumb old vim and IDEA Ultimate.
When its fast its pretty snappy though. I recently put revisiting emacs on my todo-list, should add taking Zed out for another round as well.
alfiedotwtf
I think that’s the same issue I’ve had with i3 and the sole reason why I switched to bspwm. I think it happens when the cursor is on a GPU accelerated window and you quit the app - it’s like i3’s keyboard input gets trapped in that pane and can’t escape (my work around was to create a terminal and kill the GPU app with skill using my mouse)
littlestymaar
That sounds a lot like a CPU fallback of the rendering that should otherwise happen on the GPU. Isn't there any logs that could suggest that this is the case?
Edit: I just saw your edit to your reply here[1] and that's indeed what's happening. Now the question is “why does that happen?”.
[1]
Palmik
No issues on Linux for me. Much better (faster / snappier) than VS Code and forks.
airstrike
it's not even fast on macOS in my experience
littlestymaar
That's interesting[1], what was slow when you tried it on MacOS?
[1]: people experiencing sluggishness on Linux are almost certainly hit by a bug that makes the rendering falls back to llvmpipe (that is CPU rendering) instead of Vulkan rendering, but MacOS shouldn't have this kind of problems.
volkk
not sure why folks are downvoting you, but i'm not sure to be honest. i'm on an m3 pro
cies
> because the other Rust GUI libraries/frameworks aren't great.
Iced, being used by System76's COSMIC EPOCH, is not great in what regards? Serious question.
volkk
there's basically zero documentation for Iced as it stands. They even wrote that if you're not a great Rust dev, you're going to have a bad time and that all docs are basically "read the code" until their book is written. I'm glad System76 is able to build using Iced, but you need a great manual for a tool to be considered mature and useful.
IMO Slint is milestones ahead and better. They've even built out solid extensions for using their UI DSL, and they have pages and pages of docs. Of course everything has tradeoffs, and their licensing is funky to me.
airstrike
The crate is 100% documented. what specific documentation do you think are lacking? Tutorials? That's for users to write.
Calling iced not useful reads like an uninformed take
rice7th
Then you should try egui. It has a lot of examples and it is among the most mature libraries along with iced and slint, without the licensing problems
jenadine
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
I wouldn’t hold my breath. GPUI is built specifically for Zed. It is in its monorepo without separate releases and lots of breaking changes all the time. It is pretty tailored to making a text editor rather than being a reusable GUI framework.
volkk
i don't think that's quite true based on this repo: https://github.com/zed-industries/create-gpui-app
i think there's some desire from within zed to making this a real thing for others to reuse.
jenadine
That repo is to download a small template (why do we need a crate for that?), and it still pulls `gpui` directly from the Zed monorepo via a git dependency.
That kind of setup is fine for internal use, but it’s not how you'd structure a library meant for stable, external reuse. Until they split it out, version it properly, and stop breaking stuff all the time, it's hard to treat GPUI as a serious general-purpose option.
rapnie
> because the other Rust GUI libraries/frameworks aren't great.
Waiting for Robius / Makepad to mature a bit more. Looks very promising.
xmorse
I would love having gpui bingings for JS using NAPI, now using it from Rust is too slow, Rust feedback loop is too long
jflessau
I’m developing in TS and Rust for the most part.
Went from Atom, to VSC, to Vim and finally to Zed. Never felt more at home. Highly recommend giving it a try.
AFAIK there is overlap between Atoms and Zeds developers. They built Electron to built Atom. For Zed they built gpui, which renders the UI on the GPU for better performance. In case you are looking for an interesting candidate for building multi platform GUIs in rust, you can try gpui yourself.
lispisok
People have been using editors that look comparable for decades that dont need fancy GPU rendering to be fast and responsive. What is happening that stuff like that is necessary now?
vanviegen
GPU rendering in some form or another (mostly just bitblitting characters, I guess) has also been common for decades. Classic hardware text mode is basically just that. Also, display densities and sizes have gone up (for some of us).
oblio
> Classic hardware text mode is basically just that.
I highly doubt that, unless you consider bitblting to be hardware accelerated.
When people say "GPU render" they mean 3D accelerators from the line of Voodoo onwards, not regular 2D graphics cards.
xpe
The first time I used Zed, I really noticed and appreciated the very low latency between a keypress and visual result. It created a great sense of “connection” to the experience. (I’ve previously used VS Code, Emacs, Sublime Text, JetBrains, and others)
seafoamteal
I generally use Neovim, but Zed was the first code editor that made me go, "Wow, I can see myself actually using this." My only gripe is the "Sign In" button at the top that I can't seem to remove.
But apropos TFA, it's nice to see that telemetry is opt-in, not opt-out.
pimeys
Yeah. I've been using vim since the 90's. A bit of emacs here and there, and more recently some helix too. Zed was the first GUI editor that took me over. I've always hated VSCode, but Zed is so fast and its UI just clicks on me that I've been using it as my main editor for months now.
Subscribed to their paid plan just to keep the lights on and hoping it will get even better in the future.
terminalbraid
> that I can't seem to remove
It's open source, builds extremely well out of the box, and the UI is declarative.
charcircuit
Sorry if this is obvious, but have you tried signing in?
aaravchen
Not OP, but the Sign In button is for GitHub on Zed. Which conflicts with GitHub sign in for any of the other AI agents, so you have to pick only one (the others will time out and do nothing after the first). On work machines I use the corporate Copilot login, so I just have a permanent Sign In button in the upper right that doesn't function and can't be hidden.
Also I don't want to pay with my private data from some of my systems. So I don't ever want to sign in on those systems and just have a useless button sitting there.
seafoamteal
I had a reply typed out to the parent but decided I didn't want to take the bait, so thank you for putting my concern (your second point) into words.
mirawelner
It’s funny that they lead with AI tools. I love zed because it’s fast, customizable, has a clean interface and it’s easy to pair program. The LLM bit is just an annoying thing I shut off because imo I’m too junior at the moment to use LLMs
sitkack
As someone who has 35 years of programming experience and now vibes half the day, this is a refreshing take from a junior programmer.
One way you could use LLMs w/o inducing brain mush would be for code or design reviews, testability, etc.
If you see codebases you like, stash them away for AI explanation later.
pornel
There are fast and customisable editors already. AI assistance is a green field where there's a new opportunity to be the first/best.
erk__
Is it possible to shut the AI things off? As in properly hide all the buttons and stuff that relates to it?
shantara
I was interested in zed as I was looking for a performant VSCode replacement, but its inability to fully remove AI integration and disable the prominent sign-in button made me lose any interest. Judging by the project’s response or lack of it on these topics, I am worried about adopting zed in my workflows.
anderber
Yes, you can. Just edit your settings: { "features": { "edit_prediction_provider": "none" } }
aDyslecticCrow
Its a small button in the top right corner. Very oit of the way unless interacted with. I use zed because its faster and cleaner than vscode. I dont want AI in my editor.
outcoldman
I am amazed how well it works. Yesterday I have spent a full day with a new macOS project with idea in my head. Spend half a day writing basic features, and after that opened the project in Zed to add features. Not very well documented things like AppKit + SwiftUI integration - no issues, and I mean I was getting about 500 new lines from my questions and was getting compilable code (and working). A few times after review I modified a few things to make it compilable/or better. But still. And I had one interesting problem with objc/swift and javascript integration - and Zed AI delivered some masterpiece in JavaScript, that is definitely outside my knowledge. This technology is definitely going to change how we program now.
camjw
a bit offtopic but whats your workflow for building macos products using a different editor to xcode? i am new to this and xcode seems awful (?)
LinusU
(not the one you asked, but can chime in with some info)
This was a long time ago, but the way I did it was to use XcodeGen (1) and a simple Makefile. I have an example repo here (2) but it was before Swift Package Manager (using Carthage instead). If I remember correctly XcodeGen has support for Swift Package Manager now.
On top of that I was coding in VS Code at the time, and just ran `make run` in the terminal pane when I wanted to run the app.
Now, with SwiftUI, I'm not sure how it would be to not use Xcode. But personally, I've never really vibed with Xcode, and very much prefer using Zed...
1: https://github.com/yonaskolb/XcodeGen 2: https://github.com/LinusU/Soon
camjw
Thanks this is super useful! Really appreciate it!
dimaor
I'm not sure, it might have changed since, but my personal experience was different.
Tried using zed on Linux (pop os, Nvidia) several months ago, was terribly slow, ~1s to open right click context window.
I've spent some time debugging this, and turns out that my GPU drivers are not the best with my current pop os release, but I still don't understand how it might take so long and how GPU is related to right clicking.
Switched back to emacs, love every second. :)
I'm not sure if title referring to actual development speed or the editor performance.
p.s. I play top games on Linux, all is fine with my GPU & drivers.
aaravchen
This.
It seems Vulkan support, the only GPU rendering API Zed uses, isn't well supported by any of the Debian derivatives. The libraries are only installed and working in Ubuntu 24.04 in Gnome Wayland sessions for example (Ubuntu 24.04 doesn't have KDE new enough for Wayland support).
And there are also bugs in the Zed automatic GPU selection that will intermittently cause it to pick the wrong GPU in a system with multiple (E.g. a discreet GPU and a motherboard with integrated graphics). Vulkan can only run on the primary rendering GPU, but it doesn't always pick that one, and doesn't support trying any others after the first one or picks (it seems), so it just falls back to emulated.
For reference, I had to spend 4 days getting Zed to install as part of a Nix home-manager config with nixGL because out of the box it failed to use the GPU on 2 of 3 systems. But after forcing it to use the right GPU with a wrapper that had Vulkan support (a nixGL wrapper) all 3 systems worked fine (so it's a Zed assumption/bug problem).
Also, the fact that Zed without the Vulkan supported hardware rendering is unusably slow is a big problem. It's far slower than anything else on the system and cranks the CPU to 100 with its "emulated GPU" workaround. That's not acceptable, they really need to get at least basic performance for the seeming majority of target systems that don't/can't meet the hardware rendering needs.
adriano_f
I also tried Zed on Linux a few months back, and had GPU/driver issues, so it was either slow or didn't run. Tried it just now and it worked right out of the box, and it's incredibly fast.
I will keep playing around with it to see if it's worth switching (from JetBrains WebStorm).
jjice
I know they started on MacOS and their Linux support is relatively new, so I wonder if that "fastest" label is really only applicable to MacOS currently.
constantcrying
No. It works incredibly well under Linux.
Nvidia drivers in particular are terrible on Linux, so what OP is describing is likely some compatibility/version issue.
dimaor
maybe you right, but it was weird that everything else was working perfect. rendering engines, games, other graphic things...
that is why I commented, since was disappointed a bit
SafeDusk
Tried Zed and Cursor, but they always felt too magical to me. I ended up building a minimal agent framework that only uses seven tools (even for code edits): read, write, diff, browse, command, ask, and think.
These simple, composable tools can be utilized well enough by increasingly powerful LLM(s), especially Gemini 2.5 pro to achieve most tasks in a consistent, understandable way.
More importantly - I can just switch off the 'ask' tool for the agent to go full turbo mode without frequent manual confirmation.
I just released it yesterday, have a look at https://github.com/aperoc/toolkami for the implementation if you think it is useful for you!
thestephen
Counterpoint: Zed wins me over because the LLM calls don't feel like magic - I maintain control over API calls unlike Cursor, which seems to have a mind of its own and depletes my API quota unexpectedly. Plus, Zed matches Sublime's performance unlike Cursor's laggy Electron VS Code foundation.
slowmovintarget
Sounds similar to gptel[1] for Emacs. It provides a solid foundation for more complex compositions like gptel-aibo[2] or mcp.el [3].
Yours is the full agent, though... Nice.
[1] https://github.com/karthink/gptel
SafeDusk
For sure! I'm surprised myself how far one can get with just seven tools: read, write, diff, browse, command, ask, and think.
It's like lisp's original seven operators: quote, atom, eq, car, cdr, cons and cond.
And I still can't stop smiling just watching the agent go full turbo mode when I disable the `ask` tool.
bergheim
It's amazing. Just like you keep repeating full turbo, I hope we all go full turbo, all the time! Who needs thoughtful care in these things anyway, that's for another day! Lets goooo
shinoxzu
> I ended up building a minimal agent framework that only uses seven tools
you can choose which tools are used in zed by creating a new "tools profile" or editing an existing one (also you can add new tools using MCP protocol)
xpe
Zed and Cursor are very different; I wouldn’t put them in the same bucket myself. I’ve been using the Zed AI assistant panel for a while (manual control over the context window by including files and diagnostics) — will try the new agentic panel soon.
dtkav
Unfortunately the new agent panel completely nerfs the old workflow. I also love the old version (now called "Text Threads") for its transparency.
Even though they brought back text threads, the context is no longer included (or include-able!) as context in the inline assist. That means that you can no longer select code, hit ctrl+enter, and type "use the new code" or whatever.
I wish there was a way to just disable the agent panel entirely. I'm so uninterested in magical shit like cursor (though claude code is tasteful IMO).
freehorse
Actually, I just checked and an active text thread is added to the inline prompt context (you may need to click on the box at the bottom of the inline prompt to include it, but then it is added by default for the next). So it looks fine to me (and it is nicer that it is more explicit this way).
There is also the "+" button to add files, threads etc, though it would be nice if it could also be done through slash commands.
maxbrunsfeld
You can still include Text Threads as context in the inline assist prompt with @thread "name of thread", or using the `+` button. And it should suggest the active text thread for you, so it's one click. Let us know if that isn't working, we wanted to preserve the old workflow (very explicit context curation) for people who enjoyed previous assistant panel.
pseudopersonal
I would love a vim plugin for this. Many LLM vim plugins started off beautifully minimal, but became too agentic in their chase of Cursor.
deepsquirrelnet
Maybe once all of this is a bit more mature we can just get down to the minimal subset of features that are really important.
I’d love a nvim plugin that is more or less just a split chat window that makes it easy to paste code I’ve yanked (like yank to chat) add my commentary and maybe easily attach other files for context. That’s it really.
valzam
I can highly recommend gp.nvim, it has a few features but by default it's just a chat window with a yank-to-chat function. It also supports a context file that gets pasted into every chat automatically (for telling the AI about the tools you use etc)
ilikegreen
Last time I used it, Avante was pretty much nailing what you are describing.
hugodrax157
Have you seen CodeCompanion (https://github.com/olimorris/codecompanion.nvim)?
SafeDusk
That is the dream! Would love someone to create a vim plugin for this, if not I'll do it myself if there is enough demand.
upcoming-sesame
How do you run it in VSC using MCP?
SafeDusk
Ideally, just start the server - which is a SSE based and supported by any MCP client out of the box.
Then, connect it using this line: `client = MCPClient(server_url=server_url)` (https://github.com/aperoc/toolkami/blob/e49d3797e6122fb54ddd...)
Happy to help further if you run into issues.
bee_rider
What’s SSE? I guess this isn’t about vectorization.
kristopolous
I'm doing something similar https://github.com/kristopolous/llmehelp
The goal is composable semantic routing -- seamlessly traversal between different tools through things like saved outputs and conversational partials.
Routing similar to pipewire, conversation chains similar to git, and URI addressable conversations similar to xpath.
This is being built application down to ensure usability, design sanity and functionality.
baby
what is "think"?
SafeDusk
It is based off https://www.anthropic.com/engineering/claude-think-tool.
baby
ah interesting! Is it something that openAI also is thinking about? Or is it something that reasoning model are already doing anyway?
freehorse
I tried the agent mode with sonnet 3.7 (not the thinking one). When it started trying to create a file, it kept getting a "Failed to connect to API: 400 Bad Request" error. After a few attempts to create files, it "touch"ed a file and tried to edit this, which also failed. It checked permissions with "ls -la", then it tried to "cat" the code into it but failed because of syntax errors (to do with quoting). Then it tried nano(?!?!) and failed, and then it started "echo"ing the code into the file chunk by chunk, which started working. After 4 chunks it got an error and then it made the following chunks smaller. It took it a dozen "echo"s or so.
While the initial 400 error is a bummer, I am actually surprised and admire its persistence in trying to create the file and in the end finding a way to do so. It forgot to define a couple of stuff in the code, which was trivial to fix, after that the code was working.
rtfeldman
Zed employee here - that sounds like a bug, sorry about that!
If you're okay sharing the conversation with us, would you mind pressing the thumbs-down button at the bottom of the thread so that we can see what input led to the 400?
(We can't see the contents of the thread unless you opt into sharing it with the thumbs-down button.)
freehorse
No problem, and thanks for the response here! I sent two feedback threads (added a second test where a file succeeded to edit and the rest failed). It was actually quite entertaining seeing the model try troubleshoot stuff anyway.
I used github copilot's sonnet 3.7. I now tried copilot's sonnet 3.5 and it seems to work, so it was prob a 3.7 issue? It did not let me try zed's sonnets, so I don't know if there is a problem with zed's 3.7 (I thought I could still do 50 prompts with a free account, but maybe that's not for the agent?).
maxbrunsfeld
Thanks for the information. We can reproduce this using Copilot Chat. We're fixing now. We'll let you know when the fix is out.
maxbrunsfeld
I believe this PR fixes the issue: https://github.com/zed-industries/zed/pull/30178.
I interned at zed during the summer of 2022, when the editor was pre-alpha. Nathan, Max, Antonio are great guys and build software with care. I'm happy to see the editor receive the success it deserves, because the team has poured so much world-class engineering work into it.
I worked with Antonio on prototyping the extensions system[0]. In other words, Antonio got to stress test the pair programming collaboration tech while I ran around in a little corner of the zed codebase and asked a billion questions. While working on zed, Antonio taught me how to talk about code and make changes purposefully. I learned that the best solution is the one that shows the reader how it was derived. It was a great summer, as far as summers go!
I'm glad the editor is open source and that people are willing to pay for well-engineered AI integrations; I think originally, before AI had taken off, the business model for zed was something along the lines of a per-seat model for teams that used collaborative features. I still use zed daily and I hope the team can keep working on it for a long time.
[0]: Extensions were originally written in Lua, which didn't have the properties we wanted, so we moved to Wasm, which is fast + sandboxed + cross-language. After I left, it looks like Max and Marshall picked up the work and moved from the original serde+bincode ABI to Wasm interface types, which makes me happy: https://zed.dev/blog/zed-decoded-extensions. I have a blog post draft about the early history of Zed and how extensions with direct access to GPUI and CRDTs could turn Zed from a collaborative code editor into a full-blown collaborative application platform. The post needs a lot of work (and I should probably reach out to the team) before I publish it. And I have finals next week. Sigh. Some day!