The Zed editor seems kind of silly to me. I would rather my editor works in many possible environments maybe even one that only has a tty interface.
What advantages are people finding with this editor other then high fidelity scrolling.
The Zed editor seems kind of silly to me. I would rather my editor works in many possible environments maybe even one that only has a tty interface.
What advantages are people finding with this editor other then high fidelity scrolling.
Early Zed user here.
There’s a lot of small things you’ll hit if you use Zed where it’s a subtlety nicer design point, but one of the big ones for me is project-wide search. Zed’s multibuffers are SO much better than VS Code’s equivalent.
If I’m debugging something on a coworkers laptop, VSCode is mostly usable until I hit that.
If you’re a craftsman, it’s worth trying different tools!
Agreed, multibuffers are such a huge QOL feature. I love being able to work across a dozen or more buffers at once with no impact on performance. You can work in so many places at once, navigate from the buffer to its file and back, widen the buffer up or down, etc. It feels like a super power.
A lot of people use VSCode. Zed's value proposition is being basically that but with fully native code, so without the madness that is Electron. If you're not a fan of this kind of tooling, it's totally fine, but many people see the value in having an extensible graphical code editor
Is Zed really fully native?
Last time I tried it (few months back) it felt really slow. Truns out it was spawning nodejs servers and using tons of memory.
Honestly, vscode was much faster for me (and looked much better).
Zed us, in fact, fully native. It's top-to-bottom Rust, which gives them C++ equivalent speeds or better compiles to native code and lets them much more easily make use of multi-threading parallelism than basically any other language that compiles to a static binary. They also use a custom GUI framework built from the graphics driver's up to be maximally efficient, performance smooth and low latency; that's literally the subject of this thread!
The only reason it would be spawning Node.js processes is if it's running a javaScript/typescript language server for you, but that's not a property of Zed itself, it's something any other editor would do (including VS Code). Also, the resident memory of Zed, even with multiple entire projects with hundreds of tabs open, running several language servers and multiple terminals and AI agents for me never exceeds about 900 megabytes, which is significantly less than VS Code uses even at startup.
Whatever it was that you ran into, it's likely some kind of fluke or platform-specific bug.
My tone probably came off as antagonistic and that was not my intention. I was interested in if anyone was using the high fidelity graphical features for something other then making the environment prettier.
I am always interested in what features new editors and how people use them and such and if I am missing out.
As far as I can tell, no. I moved to zed from nvim for fast starts + better AI UX with edit prediction & agents than nvim without start time/RAM of cursor. It delivered on that, but now that I think about it my coding practices have changed so much since that decision (sitting in Claude / https://www.conductor.build) I should probably just go back to nvim!
Idk, I use Zed because it's so dang smooth. On a 144hz screen it feels really nice to use, other editors like v$code and IntelliJ have noticeable stutter and I find that to be distracting, in the same way it's jarring to go back to a 50hz monitor after getting used to 144.
It's not clear to me why you would want your editor to run in as many environments as possible unless you're a system administrator? Generally, most of us do our serious coding work on the major OS platforms and we would want a native editor that takes advantage of those platforms and the hardware they tend to run on maximally; if we need to edit something on some other box elsewhere, we could either use Zed's remote development system or just use MicroEmaca Nano or VI depending on which key bindings were used to.
The advantage I find personally, at least compared to something like emacs, is not just that you get high fidelity scrolling, but that the editor can open 60,000 line code files instantaneously syntax highlight all of it using trees that are and be butter smooth and responsive the entire time I'm searching through making multi-cursor edits or moving through the file. As well as being able to open for instance log files that are multi-megabytes large without having to worry about anything.
Plus, Zed has a lot of refinements and features over other editors, even if you discount the benefits of GPUI. I've spoken at length before about why I think its approach to coding agents is the best at sort of enhancing the human in the loop and keeping you in a flow state and preventing skill degradation[0], but I also think the range and design of the editing actions are better than almost all modern text editors, closer to what something like Emacs provides, and the UI is overall more streamlined and pleasant to use than something like VS Code, even though it's generally the same philosophy. There's also the collaboration features and the edit predictions.
[0]: https://news.ycombinator.com/item?id=46995110
> It's not clear to me why you would want your editor to run in as many environments as possible unless you're a system administrator?
All I really was trying to say is that one may find themselves in a more limited environment at some points, I was not so much thinking of remote editing for the reason you mentioned that most developers or even system admins(unless restricted for security reason or some other) can just remote in and most editors these days do this well. but in a situation where one may be installing their system or their graphics acceleration has broken for what ever reason and now one is without their trusty editor so although I hardly every use emacs in a tty or pty it's a fallback in case something goes wrong so I can fix it while still using my editor.
>that the editor can open 60,000 line code files instantaneously syntax highlight all of it using trees that are and be butter smooth and responsive the entire time I'm searching through making multi-cursor edits or moving through the file.
this definitely sounds interesting, emacs when dealing with very large log files and such is not always fantastic and some features become painfully slow or completely unusable .
Your other points on the AI features are interesting I have been using Aider and tried aidermacs but ended up going back to a shell buffer with some basic commands to switch back to the buffer and other features to control it, while in one of the code buffers. So will definitely look at some of the AI features when I give it a spin.
I wanted to check the hype, so I installed Zed and opened a go project.
Ram usage:
VS Code 580 MB
Zed 410 MB
I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.
Try Sublime Text if you want lower RAM usage. My instance is currently sitting at ~120mb with 3 separate projects open (that does not include usage by Rust Analyzer which runs in a separate process (and tends to use GBs of RAM), but I suspect your numbers don't either)
Kind of there with you... was pretty surprised how big the surface was with Zed, and it definitely doesn't do all the things I do in Code currently.
How much of the RAM usage is by gopls (The Go LSP)?
Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what.
I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different
> Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what.
LSPs, they are snagging the LSPs made by other developers for languages you are using. if you install any LSP or language support in VSCode its running the same thing. It only installs when you are using a language that has default support such as Rust, Python (which I believe uses a Node.js LSP), Go (same as Python), etc.
what about CPU usage? Overall I agree, it doesn't have enough plugins and is not well supported yet.
Currently Zed uses more CPU than VSCode on my Windows and macOS laptops.
Does Zed have cursor-like tab completion yet?
Yes: https://zed.dev/docs/ai/edit-prediction
Thanks. Have you used cursor or copilot (recently, tab completion has gotten better)? I'm curious how this compares in actual performance. Last time I used Zed, this was a showstopper as the completions were much worse (though if I configure it to use copilot as my source, I guess it should perform the same as VsCode?).
Personally, I don't like this autocomplete or tab-completion thing. I find it very distracting. I understand why someone might like it, but it's just not my thing. I mostly use Claude (and Codex) through ACP in Zed. My colleagues use Cursor and VSCode, and I don't feel like I'm missing anything at all.
I came from nvim after using vim for decades. For me, you could approximate Zed with endless hours of tinkering in nvim, or I could just use Zed.
Things that keep me: fast. Easy project wide search that is fast. Easy file completion that is fast. Easy ability to add/remove line numbers from a gutter. Vi keys that... kinda mostly work. Sorta. Code collapsing that I didn't have to spend hours fidgeting with that also mostly works with Ruby (except for rescue clauses / end-of-function exception handling which collapses weirdly.)