I'm very happy to see work on the debugger. This is the main feature preventing me from switching full time to zed.
Unfortunately, "here" is not accurate. Not having a watch window, a stack trace view, and no mention of data breakpoints in the announcement still keeps the "beta" tag. I know those features will arrive eventually, but what is described is definitely not sufficient for 97% of my debugging sessions.
I would also have liked to see more in the announcement of multiple simultaneous debug sessions, and on how multithreaded debugging is planned. There are really cool things that can be done with multithreaded debugging further down the line that I'd be interesting in hearing about (like how RemedyBG has a DAW-like UI for freezing certain threads, or hitting one button to "solo" a thread and freeze all others).
Hey Laserbeam, I'm one of the devs that made the debugger and the one that wrote the article.
We do have a basic stack trace view that basically all debuggers support. What's coming out in the near future is a stack trace view in our multi buffer system. In fact, you can use the "show stack trace" action while in an active debug session to expand the call stack in a multi buffer, where each excerpt is a frame. It's just not up to the quality that I and several others expect from Zed, so I didn't advertise it.
There's also a PR for a watching variables/expression that is going to be merged in a couple of days. The functionality is done, but we didn't want to add a feature so close to launch that wasn't fully tested.
Support for data breakpoints will come in the near future. I can't say when because we're planning on focusing on automatic configuration for a while, but it is a priority.
We do support simultaneously debugging multiple sessions at the same time and multithreaded debugging too. There's still more to do with it, but the support is definitely there!
The blog post mentions[1] that advanced views are in development. This initial release and announcement focuses on the underlying foundation they're building upon.
> New views: While we support all the fundamental views, we're planning on adding more advanced views such as a watch list, memory view, disassembly view, and a stack trace view
I have to try out the debugger yet. However I share your sentiment but for the Git feature. The basics are there but it is just not complete yet to fully replace my current git workflow. Hope they keep focus on that as well.
Zed is fantastic. I've been making the leap from neovim to zed lately, and it's been an great experience. Everything feels snappy, and I love how well they've integrated Vim bindings. Their agent mode is nice as well.
It's clearly an underdog to VSCode, so the extension ecosystem isn't quite there yet... but for a lot of the things I've used it for, it's sufficient. The debugger has been the big missing feature for me and I'm really glad they've built it out now - awesome work.
I love how fast Windsurf and Cursor are with the "tab-tab-tab" code auto-completion, where nearly everything suggested is spot-on and the suggestions keep on rolling, almost automating the entire task of refactoring for you. This form of autocomplete works really well with TypeScript and other scripting languages.
IntelliJ / RustRover never got anywhere close to that level of behavior you can get in Cursor and Windsurf, neither in conjunction with JetBrains own models or with Co-pilot. I chalked it up as an IDE / model / language mismatch thing. That Rust just wasn't amenable to this.
A few questions:
1) Are we to that magical tab-tab-tab and everything autocompletes fluently with Rust yet? (And does this work in Zed?)
2) How does Zed compare to Cursor and Windsurf? How does it compare to RustRover, and in particular, JetBrains' command of the Rust AST?
Every time I've encountered a vim emulator I've found it is just close enough that my fingers are doing the wrong things so often it's frustrating. Almost to the point where I would prefer a non-vimmy editor since at least then my fingers always do the wrong thing.
Zed was the first editor that tempted me into using AI features. It felt solid in general and AI feels mostly like autocomplete in other editors (in terms of how much it's in your face). There's definitely a place for AI models and agents in code editors, and Zed makes me feel like it's not built around them, which is great! Zed feel like "Come to us, we are making a good fast editor that also has AI." while competition feel like "Come to us, we want AI that has an editor".
I went to check out neovim and noticed it's currently sponsored by two AI products! Of course, that's one level removed from actually integrating AI in your product but, still—it's getting harder and harder to avoid altogether.
The AI features in Zed are very easy to turn off / ignore. I agree that the AI features are probably taking development time away from other features that might be more useful.
Zed feels like what Lapce, Helix and Neovim couldn't achieve in the time they spent.
I started using Helix back around 2021-2022 and just couldn't get over the bugs and lack of integration. It was good, but PHP support (I was working at an older company) was bad.
Neovim felt closest to a nice editor but there were some popular community-driven plugins that were very stubborn, and alternatives were just very slow. I was also just overwhelmed by the choices I needed to make for something stable.
Lapce just felt like a VSCode clone that didn't do anything special. Looked cool, but I did not feel like it was ready for a daily driver (And it still doesn't).
Zed became a favorite in a short amount of time, and I'm extremely grateful for it every day. The debugger is a nice addition.
This might be off-topic, but I really want to use Helix. I've been using Vim keybindings for a few years now but it's so unintuitive, there's still so many things I can't do efficiently in Vim. Helix just makes so much more sense for my brain. But I don't use Vim/Neovim by itself, I always use an integration with an editor like VSCode or Obsidian (Obsidian's Vim emulation isn't great, but it's good enough). Helix just isn't there yet with VSCode or Obsidian.
I wish more "Vim successors" would focus more on integrating with existing IDEs, rather than becoming one themselves. I don't want to have to set up an entirely new workflow when I change how I edit text.
That's also why I haven't tried using Neovim as a standalone IDE. It looks like I'd really like it, but I don't want to be locked in to using Vim.
Ever since Linux support came out (2 years ago?), I go to check if they, finally, support “non-retina” “LoDPi” (a.k.a: a regular screen) yet, and sadly no :/
I think competent software engineers should actually read the "Under the hood" section, before they lose the core understanding on how debuggers work and are integrated into editors.
Upon reading the Rust code implementing the Debug Adapter Protocol (DAP) in Zed, some very junior SWEs will quickly point out that they would prefer only "self-documenting code" and would go as far as to removing all comments or even believe that "If it has comments, its probably bad code".
For sophisticated software that implements a defined protocol that is architected to be scalable in any piece of complex software, I prefer these comments that explains why a particular interface is designed the way it is and how it fits into the software (Zed) in this case if it were to be widely re-used like a plugin system.
This blog post is excellent in explaining this debugger integration in the editor and it makes me want to consider using Zed; it just needs an improved extension ecosystem.
If be surprised if Zed aren't dogfooding their own AI agents to help writing some of the Zed code. The AI often put a lot of comments on the generated code, and sometimes needs a lot of comments to produce the right code.
It's surprisingly slow. Switching files in the tab list has a noticeable delay. Typing is higher latency than both Emacs (lsp-mode activated) and my web browser. Also uses approximately 60MiB more than my Emacs. It starts fast though!
I wouldn't complain about this stuff if it wasn't for their tagline being 'it's fast' and they're losing to Emacs Lisp (not a language amenable to being very fast) with a highly optimized C core.
I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
How did you manage to make zed slower than emacs? From my experience, latency in zed sometimes even feels negative. Everything is instant: editing, lsp commands, file switching
In contrast, all my attempts at emacs ended up in dropping it due to latency issues (mostly because I work on remote machines)
> I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
No. The ones I've looked just set up stuff, like launching a language server. They shouldn't be involved in typing.
I think it's related to the GPU usage. It's easy to introduce delays when you do GPU compositing, and the OS will already be doing its own.
As for emacs, IIRC they did some ugly things to update the UI directly instead of going through the normal event loop, which was causing compatibility issues later on.
I really want to switch to Zed from Cursor but the battery usage for my Python project with Pyright is unjustifiable. There are issues for this on GitHub and I'm just sad that the team isn't prioritising this more.
It’s funny you mention this because I have an issue with Cursor where if I leave it open for more than a few hours my M3 Max starts to melt, the fans spin up, and it turns out to be using most of my CPU when it should be idling.
Zed on the other hand works perfectly fine for me. Goes to show how a slightly different stack can completely change one’s experiences with a tool.
I've gone full-time with Zed for the past month or so and really like it. Love the fast start times. There was a blurry font issue on linux, but that seems to have been fixed for me. Not sure what caused it.
dear zed ppl, PLEASE PLEASE PLEASE configure your language detection properly wrt C and C++! every single editor on earth makes this exact same mistake where they think all C is valid C++ (it's not, at all), and mistakenly recognises C files as C++, even when there's an accompanying compile_commands.json file that specifies a C standard and even when files contain invalid C++ (but valid C)
it's a delightful little editor if it weren't for this thing...
You can customize the rules for detecting a language by file name/path in your settings. The problem is in cases like creating a new file the editor has to guess.
I like some of their choices, but I wouldn't say that releasing your product for a minority operating system only, then following up with yet another minority operating system much later, then stuffing AI features in there when you don't even have debugger support... The list goes on; one man's "real product development" is another's list of mistakes.
They got the baseline feature set right, IMO, but probably could've spent some more time looking at the actual, real demographics of development (and who is most likely to appreciate performance as a feature and share those ideals).
For some reason I've found myself wanting a "lighter VS Code" lateley, which is ironic considering I used VS Code for the past 10 years because it is so lightweight. So I've wanted to try out Zed, but it's just ... weird to go back to a closed source editor, especially one that's so focused on imitating copilot, which seems like an odd feature to shift most focus on.
It's a niche feature, but what's keeping me from switching yet is that they zed doesn't support ctrl+scroll to zoom/change font size yet.
Because I am accustomed to a non-US keyboard layout that doesn't make the regular key bindings for changing zoom easy, I got too used to doing it this way.
It's honestly looking to be a great modern IDE with almost everything I'm wishing for.
It is funny that accidental scroll while holding Ctrl changing font size is one of my most hated features in IDEs, like who the hell ever needs to change their optimal font size to any other value. It's fascinating to me that this is a dealbreakingly important feature for someone else.
> To simplify the setup process, we've introduced locators, a system that translates build configurations into debug configurations. Meaning that you can write a build task once in tasks.json and reference it from debug.json — or, even better, rely on Zed's automatic configuration.
I've been using the unofficial builds via scoop for the last two months. It's working great so far. I use it on a Macbook as well and I haven't found any features that are missing or buggier on Win11. Really enjoying the new agent version of the AI assistant, which I use with both Claude API and devstral locally via Ollama.
This is becoming a recurring issue; plenty of innovation being put in new and faster tooling to replace the JS-based daily drivers we've had for the past decade+, but there's a huge ecosystem of 3rd party addons to those now which is slowing adoption down; I'm also thinking of Prettier/ESLint vs Biome, the only thing stopping us from going full Biome is that we need some ESLint plugins.
That said, it's getting better; as another commenter pointed out, LSP is one of the best things to happen to this space. There should be a standard for editor plugins, too.
Zed only supports language extensions, so it is in part responsible. If you're using embedded rust then PlatformIO isn't really needed; probe-rs is extremely capable and straightforward.
I'm tempted to invest in switching to Zed full time, but there are enough small bugs with toolbars or dialog popups not working the first time that it makes me wary.
I tried using Zed for a few months, but somehow ended up with a conclusion, that VSCode serves my needs better. Just a sum of small issues, like the need to manually re-apply coloring schemes to some files.
I wonder if they advertize the editor as the most AI-enabled, how much do they vibecode the editor themselves? /s
Jokes aside, after SublimeText as the main tool, and VSCode for Rust debugging, I'm trying this one. Now with more themes and plugins than a year ago, it can be set up to look and function a lot better.
laserbeam|8 months ago
Unfortunately, "here" is not accurate. Not having a watch window, a stack trace view, and no mention of data breakpoints in the announcement still keeps the "beta" tag. I know those features will arrive eventually, but what is described is definitely not sufficient for 97% of my debugging sessions.
I would also have liked to see more in the announcement of multiple simultaneous debug sessions, and on how multithreaded debugging is planned. There are really cool things that can be done with multithreaded debugging further down the line that I'd be interesting in hearing about (like how RemedyBG has a DAW-like UI for freezing certain threads, or hitting one button to "solo" a thread and freeze all others).
anthony-eid|8 months ago
We do have a basic stack trace view that basically all debuggers support. What's coming out in the near future is a stack trace view in our multi buffer system. In fact, you can use the "show stack trace" action while in an active debug session to expand the call stack in a multi buffer, where each excerpt is a frame. It's just not up to the quality that I and several others expect from Zed, so I didn't advertise it.
There's also a PR for a watching variables/expression that is going to be merged in a couple of days. The functionality is done, but we didn't want to add a feature so close to launch that wasn't fully tested.
Support for data breakpoints will come in the near future. I can't say when because we're planning on focusing on automatic configuration for a while, but it is a priority.
We do support simultaneously debugging multiple sessions at the same time and multithreaded debugging too. There's still more to do with it, but the support is definitely there!
happy-dude|8 months ago
> New views: While we support all the fundamental views, we're planning on adding more advanced views such as a watch list, memory view, disassembly view, and a stack trace view
[1] https://zed.dev/blog/debugger#whats-next
odie5533|8 months ago
keyle|8 months ago
aequitas|8 months ago
nixpulvis|8 months ago
unknown|8 months ago
[deleted]
candrewlee|8 months ago
echelon|8 months ago
I love how fast Windsurf and Cursor are with the "tab-tab-tab" code auto-completion, where nearly everything suggested is spot-on and the suggestions keep on rolling, almost automating the entire task of refactoring for you. This form of autocomplete works really well with TypeScript and other scripting languages.
IntelliJ / RustRover never got anywhere close to that level of behavior you can get in Cursor and Windsurf, neither in conjunction with JetBrains own models or with Co-pilot. I chalked it up as an IDE / model / language mismatch thing. That Rust just wasn't amenable to this.
A few questions:
1) Are we to that magical tab-tab-tab and everything autocompletes fluently with Rust yet? (And does this work in Zed?)
2) How does Zed compare to Cursor and Windsurf? How does it compare to RustRover, and in particular, JetBrains' command of the Rust AST?
timeinput|8 months ago
Every time I've encountered a vim emulator I've found it is just close enough that my fingers are doing the wrong things so often it's frustrating. Almost to the point where I would prefer a non-vimmy editor since at least then my fingers always do the wrong thing.
mort96|8 months ago
I'll just stick with Neovim until something better comes around. Which probably won't happen until after the "AI" bubble bursts.
laserbeam|8 months ago
oneeyedpigeon|8 months ago
rckt|8 months ago
foldr|8 months ago
norman784|8 months ago
aequitas|8 months ago
ramon156|8 months ago
Furthermore, Zed Agents are currently my favorite way of using LLM's during programming
Nezteb|8 months ago
reddalo|8 months ago
seabass|8 months ago
NooneAtAll3|8 months ago
nsonha|8 months ago
[deleted]
ramon156|8 months ago
I started using Helix back around 2021-2022 and just couldn't get over the bugs and lack of integration. It was good, but PHP support (I was working at an older company) was bad.
Neovim felt closest to a nice editor but there were some popular community-driven plugins that were very stubborn, and alternatives were just very slow. I was also just overwhelmed by the choices I needed to make for something stable.
Lapce just felt like a VSCode clone that didn't do anything special. Looked cool, but I did not feel like it was ready for a daily driver (And it still doesn't).
Zed became a favorite in a short amount of time, and I'm extremely grateful for it every day. The debugger is a nice addition.
rbits|8 months ago
I wish more "Vim successors" would focus more on integrating with existing IDEs, rather than becoming one themselves. I don't want to have to set up an entirely new workflow when I change how I edit text.
That's also why I haven't tried using Neovim as a standalone IDE. It looks like I'd really like it, but I don't want to be locked in to using Vim.
user3939382|8 months ago
Not sure why PHP needs a qualifier like this.
Bolwin|8 months ago
[deleted]
hu3|8 months ago
Interesting way to qualify the most popular editor of human history.
AbuAssar|8 months ago
IMHO Debug Adapter Protocol (DAP) and Language Server Protocol (LSP) are the best things happened to programming tooling in the last decade.
(I wrote this comment in another thread about the same link but didn't hit the frontpage)
eddythompson80|8 months ago
sapiogram|8 months ago
Github issue for context: https://github.com/zed-industries/zed/issues/7992
marton78|8 months ago
jaoane|8 months ago
senko|8 months ago
rvz|8 months ago
Upon reading the Rust code implementing the Debug Adapter Protocol (DAP) in Zed, some very junior SWEs will quickly point out that they would prefer only "self-documenting code" and would go as far as to removing all comments or even believe that "If it has comments, its probably bad code".
For sophisticated software that implements a defined protocol that is architected to be scalable in any piece of complex software, I prefer these comments that explains why a particular interface is designed the way it is and how it fits into the software (Zed) in this case if it were to be widely re-used like a plugin system.
This blog post is excellent in explaining this debugger integration in the editor and it makes me want to consider using Zed; it just needs an improved extension ecosystem.
[0] https://zed.dev/blog/debugger#under-the-hood
neurostimulant|8 months ago
unknown|8 months ago
[deleted]
writebetterc|8 months ago
I wouldn't complain about this stuff if it wasn't for their tagline being 'it's fast' and they're losing to Emacs Lisp (not a language amenable to being very fast) with a highly optimized C core.
I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
nurumaik|8 months ago
In contrast, all my attempts at emacs ended up in dropping it due to latency issues (mostly because I work on remote machines)
GrayShade|8 months ago
No. The ones I've looked just set up stuff, like launching a language server. They shouldn't be involved in typing.
I think it's related to the GPU usage. It's easy to introduce delays when you do GPU compositing, and the OS will already be doing its own.
As for emacs, IIRC they did some ugly things to update the UI directly instead of going through the normal event loop, which was causing compatibility issues later on.
frou_dh|8 months ago
https://elpa.gnu.org/packages/dape.html
The way it's designed (incl. having no dependencies) suggests that they will be angling for it to be included with stock Emacs at some point.
sapiogram|8 months ago
superlopuh|8 months ago
vinnymac|8 months ago
Zed on the other hand works perfectly fine for me. Goes to show how a slightly different stack can completely change one’s experiences with a tool.
lordofgibbons|8 months ago
taminka|8 months ago
it's a delightful little editor if it weren't for this thing...
haiku2077|8 months ago
ChrisArchitect|8 months ago
DrBenCarson|8 months ago
So nice to have an option that doesn’t repackage the whole damn chromium engine (again)
59nadir|8 months ago
They got the baseline feature set right, IMO, but probably could've spent some more time looking at the actual, real demographics of development (and who is most likely to appreciate performance as a feature and share those ideals).
bitbasher|8 months ago
haiku2077|8 months ago
In Zed, login is only required for internet features like some of the commercially hosted LLMs, and the multiplayer editing feature.
mixmastamyk|8 months ago
90s_dev|8 months ago
trostaft|8 months ago
https://zed.dev/blog/zed-is-now-open-source
haiku2077|8 months ago
sureglymop|8 months ago
Because I am accustomed to a non-US keyboard layout that doesn't make the regular key bindings for changing zoom easy, I got too used to doing it this way.
It's honestly looking to be a great modern IDE with almost everything I'm wishing for.
nlitened|8 months ago
senko|8 months ago
throwaway290|8 months ago
Does that work if my build is Docker based?
haiku2077|8 months ago
rs_rs_rs_rs_rs|8 months ago
fancy_pantser|8 months ago
https://github.com/deevus/zed-windows-builds
sathyabhat|8 months ago
tomjuggler|8 months ago
I'm guessing that this extension support problem will continue to be a barrier to uptake for a while.
Cthulhu_|8 months ago
That said, it's getting better; as another commenter pointed out, LSP is one of the best things to happen to this space. There should be a standard for editor plugins, too.
zamalek|8 months ago
Zed only supports language extensions, so it is in part responsible. If you're using embedded rust then PlatformIO isn't really needed; probe-rs is extremely capable and straightforward.
nixpulvis|8 months ago
tdhz77|8 months ago
rhgraysonii|8 months ago
Rucadi|8 months ago
wiz21c|8 months ago
https://github.com/deevus/zed-windows-builds/releases
The opengl one fails on my PC but the "regular one" (?) zed.exe seems to work. Didn't test much as I have discovered that today :-)
unknown|8 months ago
[deleted]
Andrew_nenakhov|8 months ago
sedatk|8 months ago
xboxnolifes|8 months ago
desireco42|8 months ago
karunamurti|8 months ago
culebron21|8 months ago
Jokes aside, after SublimeText as the main tool, and VSCode for Rust debugging, I'm trying this one. Now with more themes and plugins than a year ago, it can be set up to look and function a lot better.
sahil_sharma0|8 months ago
[deleted]
einpoklum|8 months ago
Now, seeing that it's a GUI application, why would I use it, given that it seems to:
1. have no menus,
2. have no toolbars,
3. be AI-focused?
thoroughburro|8 months ago
yangcheng|8 months ago