← Back to context

Comment by throwa356262

1 day ago

Zed seems to have many fans on HN.

But it is not for me. Multiple issues on Linux and high memory usage makes it a worse alternative to vscode and jetbrains.

Maybe it's better on OSX, but I dont use that anymore and why use an editor that treats your platform as a second class citizen?

On MacOS I never really felt there was a noticeable performance difference to using Zed vs VSCode. I still like the idea of it being Rust/GPU based but just like those GPU optimized terminals (Kitty, Alacritty, etc) the difference is usually pretty marginal for day to day stuff.

The only time VSCode gets slow is if you use a bunch of poorly written plugins, which hasn't been an issue for me in years. It's just like Chrome, chrome is extremely fast as a base but you can mess it up by not being careful with what you add to it.

I still plan to revisit Zed in another year or so once it progresses further, as I find it's still behind Cursor in many ways.

  • This is exactly how I feel.

    Cursor works just fine for me. I just don't have the incentive to learn a new tool even though I think Zed is cool.

So I'm not so sure how you arrived at your conclusion of Zed having higher memory use than VSCODE but in testing just now that's not at all close to true.

Zed for me on my Linux machine opened to a massive C++ project (the Ladybird browser if you were curious) is (not including LSP or extension processes) using around 480MB of memory.

VSCode on the other hand with nothing open but a 20 line JSON file is (again not including any LSP or extension processes) using around 920MB of memory as reported by its own builtin task manager thing.

I suppose 480MB for a text editor might be a tad high but calling it worse than VSCode is a massive stretch.

  • If editors own memory usage is your main concern then you should use emacs or even better mg or vi.

    The editor + its plugins + it's LSP server is what counts. I dont care if zed is written in rust and uses 400MB when it spawns a multi GB nodejs process when I work on my tiny golang project.

    • I mean all 3 of those also support LSP plugins, so would also spawn "multi GB nodeJS processes" with your tiny golang projects if you enable them.

      1 reply →

I've personally found it uses significantly less memory on large projects than VSCode. VSCode has historically been nigh-unusable for me on Linux, it gets incredibly sluggish.