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
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.
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)
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.
> 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 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.)
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.
linolevan|16 days ago
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!
steve_adams_86|16 days ago
chiffaa|16 days ago
badhorseman|16 days ago
I am always interested in what features new editors and how people use them and such and if I am missing out.
throwa356262|16 days ago
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).
eklavya|16 days ago
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.
roflcopter69|16 days ago
tracker1|16 days ago
nicoburns|16 days ago
throwa356262|16 days ago
I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different
r4nd0m4ch|16 days ago
logicprog|16 days ago
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
badhorseman|16 days ago
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.
x0x0|16 days ago
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.)
slopinthebag|16 days ago
nu11ptr|16 days ago
tuzemec|16 days ago