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).
mort96 · 25m ago
I was interested in Zed, but lost all interest when they started integrating "AI". I'm tired of "AI" everywhere.
I'll just stick with Neovim until something better comes around. Which probably won't happen until after the "AI" bubble bursts.
oneeyedpigeon · 13m ago
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.
reddalo · 17m ago
Me too. I don't want AI, and if it's there, I want to be able to completely remove it. Zed is forcing it, so I'm staying on VSCodium.
nurumaik · 3m ago
What's forcing AI in Zed though?
agent.enabled = false and it's gone, no?
candrewlee · 3h ago
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.
echelon · 2h ago
How is Zed with auto-completing Rust code?
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?
WD-42 · 2h ago
Zed is written in Rust by a bunch of Rust lovers so it's really got first class support for it.
lionkor · 2h ago
It's fantastic for Rust, it's my main IDE which I've written e.g. voltlane.net in. Fantastic software, and the LLM integration is everything you need IMO (in a good way).
AbuAssar · 1h ago
I’m thrilled to see Zed evolve into a featured, lightweight IDE.
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)
writebetterc · 14m ago
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?
eddythompson80 · 2h ago
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 :/
senko · 41m ago
Using it daily on my 1920x1200 laptop screen in Linux and works just fine.
marton78 · 2h ago
It's an ugly workaround, but if you install BetterDisplay (it's a free tool) and set your LoDPI screen to HiDPI, text rendering looks good.
girvo · 1h ago
Oh I'll have to try that. Zed looks woeful on my 1440p monitor when I was trying it at work, which is a shame because I quite like it otherwise.
dkersten · 30m ago
In what way? I e been using it on my 1440p for over a year and it looks fine. Am I missing something?
GrayShade · 28m ago
On my system (Linux, 4k display without scaling) the fonts look awful, but bumping up the font weight more or less fixes it.
jaoane · 2h ago
They don’t support windows, they don’t support regular screens on Linux… are they a Mac shop basically?
Installing the 'stable' build with scoop works a treat.
senko · 40m ago
Using it with regular screen in Linux, works just fine.
LoganDark · 36m ago
Yes. Originally they were Mac-only, then they went open-source and the community added support for Linux and Windows, but AFAICT they've never invested in anything but Mac
avarun · 51m ago
Most startups are
yangcheng · 19m ago
I wish Zed can better support claude code, like offering native IDE integration. with Claude code SDK this seems doable?
sureglymop · 2h ago
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.
nlitened · 58m ago
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.
dmit · 46s ago
Live coding during a presentation or on stream is another use case in addition to the sibling comments.
j16sdiz · 16m ago
You use them in pair programming, when you peer sit a little bit further
7bit · 39m ago
I often use it when sharing my screen. I like the feature quite a lot.
senko · 38m ago
May I ask which layout is that? On most that I have encountered (using hr daily), + and - don't require modifiers.
lordofgibbons · 3h ago
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.
tomjuggler · 2h ago
Not Zed's fault but I'm still stuck with VSCode because Zed doesn't support PLatformIO (or rather PlatformIO doesn't support Zed).
I'm guessing that this extension support problem will continue to be a barrier to uptake for a while.
zamalek · 2h ago
> Not Zed's fault
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.
rvz · 2h ago
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.
I havent's keep up with Zed, how's the Windows version coming along? Is anyone here using it?
fancy_pantser · 2h ago
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.
> 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.
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).
I'll just stick with Neovim until something better comes around. Which probably won't happen until after the "AI" bubble bursts.
agent.enabled = false and it's gone, no?
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?
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)
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?
https://github.com/deevus/zed-windows-builds
Installing the 'stable' build with scoop works a treat.
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.
I'm guessing that this extension support problem will continue to be a barrier to uptake for a while.
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.
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
https://github.com/deevus/zed-windows-builds
It is finally at the review stage, I really hope it can get merged soon!
Does that work if my build is Docker based?