It is finally at the review stage, I really hope it can get merged soon!
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?
I think they all use LSP, so whether you use neovim or Zed there shouldn't be a difference? (not 100% sure, but that's my basic understanding of LSP).
RustRover has the best AST suggestions and refactoring support out there. It works in gigantic workspaces, across build scripts, proc macros, and dynamic dispatch.
The problem with RustRover has been the lackluster AI support. I've been finding AI autocomplete generally much more useful than AST understanding, though having both would be killer.
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.
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.
Otherwise maybe the platformio cli might be enough
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.
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.
https://github.com/deevus/zed-windows-builds
Installing the 'stable' build with scoop works a treat.
scoop bucket add extras
scoop install extras/zed
I use it in dark mode and I am considerably less picky about font rendering than many people commenting on such threads.
Combined, while I can see a difference if I look closely, it doesn't bother me.
My desktop monitor is 1920x1080. On my computer and display; Vim, Emacs and VSCode are all able to render their fonts crisply while Zed is a blurry mess.
Github issue for context: https://github.com/zed-industries/zed/issues/7992
This is not that surprising to me. Surely no-one wants to spend their day looking at the pixels?
My laptop display is fine. My desktop's 1440p is blurry, any external display at the office is blurry. So what? use Zed on my laptop when I'm using the built-in display, then switch editors if I'm switching monitors?
E: Actually, I suppose my Samsung counts. But the point stands w.r.t. "real computer" displays.
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.
Does that work if my build is Docker based?
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)
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).
With that said, Zed has effectively replaced all of Emacs for me, besides Magit. Additionally, typing in other editors feels noticeably higher latency than Zed :)
I've been daily driving Zed for almost a year now -- works best on TypeScript, Rust, and Go projects, in my opinion.
There's just so much functionality Zed has to build out to compete with modern editors (agentic coding, collaboration, debugging, edit prediction, task runners, version control). With that said, for pair-programming sessions with friends, Zed has been perfect since Linux gained screenshare support. However, there's a noticeable "pause in development" for collaboration in order to implement major features like Agentic Coding, and smaller-but-essential features like direnv integration, IME support (typing Japanese in the terminal used to be a clunky, error-prone task), dealing with the endless permutations of Python tooling so that Python files aren't a sea of red lines, etc.
It was a good time, but it always left me wondering how long it would last as it leaned heavily on community support for nearly everything useful outside a few packages
Such a situation makes me worry about it keeping up if popularity wanes. With JetBrains for example at least I know that paying for the editor it will keep getting proper updates and support even if it isn’t the most popular (though it is quite popular currently)
As opposed to having a weak plugin API where all progress depends on the tiny internal team.
The latter suffers more than the first if popularity wanes.
In Atom's case, its lunch was eaten by VSCode which was similar but just better. Based on web tech but with better performance and just as powerful of a plugin API. It wasn't the fact that they let people implement plugins that killed Atom, and they would have been in an even worse situation had they not had a good plugin API.
> 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 don't think there's an issue for data breakpoints, but you can make one for us
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!
Am impressed by the under-the-hood discussion though. Keep up the great work!
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 have a firewall, OpenSnitch, so don’t have to worry much about programs trying to connect. But definitely would prefer they don’t unless directed.
How does zed handle it?
features.edit_prediction_provider=none agent.enabled=false
There's additional config to set if inline assistance is automatic, only when the user presses a key, fully disabled, etc.
I guess it's always possible to return to Vim if Neovim starts showing signs of being steered by its sponsors.
A whole lot of "AI" features today are in that "solution looking for a problem" category. There's a lot of "AI" in places where it really makes no sense at all. Companies and projects are afraid of missing out on what they think could be the Next Big Thing, instead of just trying to make the best software they can.
When the AI bubble bursts, it could end up like Internet features: software gets them when it genuinely makes sense, but they won't be crammed into software which has no need for it. Or it could end up like cryptocurrency: it pretty much just disappears as people realize that they don't really have any use other than to speculate on its value and to buy drugs.
Personally, my bet is that they'll end up more like cryptocurrencies. After all, "AI" doesn't just have to be a useful feature to be worth it. It has a real cost. Companies like Microsoft and Apple and Google, as well as the venture capitalists and investment funds behind the likes of Anthropic, are currently sinking VAST amounts of capital into giving "AI" away for free or heavily subsidized. At some point, it'll need to become profitable, and I don't think many people will find that the value outweighs the real, non-subsidized costs.
But we'll see.
Just because tulips are nice doesn't make Tulip Madness a good idea. At the height of the DotCom boom consumers were buying stock at IPO prices for companies which made no sense whatsoever, because they said "Internet" or, (hence the naming) ".com"
For example Be Inc. was a vehicle for a failed Apple exec to "prove" he was the right person to run Apple, not Steve Jobs. After their runway ran out and institutions wanted nothing further to do with it, Be Inc. went IPO. They do this by saying they were an "Internet appliance" company and taking an OS with terrible networking but pretending it's good. In normal times this would attract laughter - they're offering a worse product, most likely it just tanks or never comes to market, and in the extreme case that Apple wants the CEO they're going to cut a deal with the man, not save the dead weight company. His most senior people might get parachutes but Apple has no reason to pay ordinary stock owners a penny. Sure enough those who bought at IPO rescued the institutions but were wiped out.
Plugins are relatively easy to write in nvim so I'd expect all ai stuff to come from there and be opt in.
Just like I want a terminal without AI features, which is why I'm no longer using iTerm2
Anyway, I'm happy with Ghostty since I switched away from iTerm2 and haven't paid attention to iTerm2 development much.
I won’t go near a code editor anymore without AI integrated deeply.
There is AI as a useful tool, maybe, which is at most few % of current hype. Most folks seem to end up babysitting it a lot to get something useful out of it. And then there is everything else which is mostly hype or narrow use cases. To proper typical senior managing a team I don't see much added value. It can help juniors churn out large chunks of the code but I haven't worked in 20 years in a place that values quantity of code and quick deliveries over quality.
Also very much depends on the business and specific company. In my banking mega corp, no AI is even allowed to be used even as I write it now, all popular sites are blocked and there are strict policies against. Couldn't care less, coding is such a small part of my work I don't want to lose this creative outlet by delegating it to something I need to triple check for bugs afterwards. Also with any new stuff I learn way more by implementing it myself rather than looking at pre-made code.
This is a huge thing tbh. I don't like these AI things in general so I wouldn't use them anyway, but I just can't imagine going to my clients and asking them, "Hey is it okay with you if I routinely upload all your code to these random American venture-backed start-ups?". And I really can't imagine just doing that behind their back. I couldn't really imagine doing that with an employer's code either.
Ideally I don't even use software where accidentally toggling the wrong checkbox in some settings screen results in automatically uploading client code to these American start-ups either. Now I won't pretend that my stance against AI is purely out of some principled cybersecurity concern, but it's definitely a factor.
In any case, what I see most people doing is integrating it with Claude/Copilot/etc. The security concerns specifically obviously don't apply when running it locally.
AI also isn't shoved in your face when using Zed, there's one small button on the button right.
Wait there's an always-present AI button in the normal text editing UI? That's way more prominent than I expected, I assumed it was just an option in a settings screen somewhere. I definitely don't want an AI button that's always on screen.
I just downloaded Zed to see this for myself and found not only one but two AI buttons in the lower right, one for integration with chat bots and one for their "prediction" AI. Both try to get you to log in to online services (even though, yes, a local chat bot is an option for one of them).
It seems like you can remove the chat bot ("agent") button through their config file, but I found no option to remove the "predictions" button.
Man this editor is pushing "AI" way harder than I imagined. As I said I genuinely assumed that it was just like iTerm2's chat bot integration where you could enable it in a settings screen.
It’s fair to have huge concerns over AI (I certainly do), but I don’t think it’s fair to expect IDEs to skip some of the only technology that developers (and companies, importantly) are willing to pay for in an IDE.
But all that annoying madness is distracting from how amazingly awesomely useful this stuff is. It's wild how many little quick projects I can kick out in a couple hours! Ideas just come out of my head with so much less fuss; when I don't like it I ask for something different.
My point is less to convince though about AI. I appreciate your starting sentiment here, but I really don't get the follow up?
> genuinely happy it works for you. I just don't want AI in my text editor, even if you're happy with it.
I don't see why it would bother you at all? There's a tiny little button in the status bar and a few scattered menu items that feel, to me, very easy to ignore.
It feels like someone being mad that their spreadsheet has I dunno, logarithms in it, but the person hates logarithms? It feels weird to opt in to caring against. I have a generalll abnner of thought which is "your anti-feature is not a feature", and this feels like one of those situations: i don't see why someone would cling to an editor not having a feature they don't use?
So if you’re not in the minority now, you will be in time.
This is not a “tech bro” thing (as someone else said). There is real substance to it.
Am I an AI curmudgeon? I wouldn't necessarily use that word, but it's not entirely inaccurate.
They're moving from "making awesome code editor" into yet another "buy our ai" product
Give them some time to polish, jeez.
Rust probably slows them down here, but working correctly early is preferable imho.
(This is referring to their recent integration work. The acceleration layer was usable a year or more ago.)
We're going to be adding more features to the debugger for a while
Furthermore, Zed Agents are currently my favorite way of using LLM's during programming
"agent": {
"enabled": false
}
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?
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.
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.
In contrast, all my attempts at emacs ended up in dropping it due to latency issues (mostly because I work on remote machines)
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 :-)
it's a delightful little editor if it weren't for this thing...
It's that it doesn't have an installer for Windows. That's what I was stuck on.
I could just build it... I guess.
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.
In Zed, login is only required for internet features like some of the commercially hosted LLMs, and the multiplayer editing feature.
"title_bar": {
"show_sign_in": false
},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.
Not sure why PHP needs a qualifier like this.
Interesting way to qualify the most popular editor of human history.
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.
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?
So nice to have an option that doesn’t repackage the whole damn chromium engine (again)
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).
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.
tdhz77•7mo ago
rhgraysonii•7mo ago