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.
What advantages are people finding with this editor other then high fidelity scrolling.
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!
I am always interested in what features new editors and how people use them and such and if I am missing out.
One thing that Zed doesn't solve but likely will is that I found "jump to label" style of features (I think flash.nvim is the closest for neovim?) is almost unreadable to me with inlined labels, but that's so highly specific I'm almost willing to live with it
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).
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.
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.
I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different
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.
Zed is one of the few editors, that like Sublime, are really focused on efficiency, using minimal resources (when needed) and the latency and FPS of the editor is bounds better than VS Code. It just works, better.
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.
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.
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.)