[badhorseman]

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.

[linolevan]

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!

[steve_adams_86]

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.

[chiffaa]

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

[badhorseman]

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.

[pkilgore]

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!

[chiffaa]

From this perspective - not sure, to be honest. For me an important factor was that Zed is getting way more love from its devs than my old editor of choice Helix. But also not being constrained to a cell grid is very nice in terms of readability to me.

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

[throwa356262]

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).

[logicprog]

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.

[eklavya]

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.

[roflcopter69]

How much of the RAM usage is by gopls (The Go LSP)?

[tracker1]

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.

[nicoburns]

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)

[throwa356262]

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

[drannex]

> 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.

[throwa356262]

So basically there is no getting away from javascript runtime. So why should I use zed instead of vscode then?

[drannex]

Latency, FPS, efficiency. The LSPs while beefy, are not part of the overall efficiency and are used as sub processes, so if they fail or are sluggish, they won't affect how the editor runs, if you don't want to use LSPs, then you can go ahead and disable those.

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.

[r4nd0m4ch]

what about CPU usage? Overall I agree, it doesn't have enough plugins and is not well supported yet.

[grougnax]

Currently Zed uses more CPU than VSCode on my Windows and macOS laptops.

[logicprog]

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

[badhorseman]

> 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.

[x0x0]

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.)

[slopinthebag]

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.

[nu11ptr]

Does Zed have cursor-like tab completion yet?

[tuzemec]

Yes: https://zed.dev/docs/ai/edit-prediction

[nu11ptr]

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?).

[tuzemec]

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.

[nu11ptr]

I am primarily using Claude as well, but I still have my old fix from Cursor, and as long as it is accurate like Cursor, I like it, if it falls below that level of accuracy, I find it annoying.