I love Zed but this has all the hallmarks of something being totally rushed out the door.
It works off the Claude Code SDK, which mean it doesn't support many of the built in slash commands - it doesn't support /compact, which is 100% necessary because when you use this implementation enough, you'll eventually get a "Prompt too long" error message with no ability to do anything about it. Since you can't see how far you are in the context window, it's a deal breaker, since you have to start a fresh chat and might run out of room before you can ask it to create a summary prompt for continuing.
There is no way to switch models that I can tell - I think it just picks up on your default model - and there is no way to switch to Plan mode, which has become absolutely crucial to my workflow.
I didn't see Zed picking up on problems reported in the IDE, it was defaulting to running 'tsc -b' in my directories.
At this point it's better to run a terminal inside Zed and work from there. The official response in the Zed Discord has been "talk to your local Anthropic rep" to get them to support Zed's Agent Client Protocol (ACP).
The Agent Model came out very recently, I’ve been following the GitHub issue over the past days and you can see it was rushed out. But I don’t see anything wrong with that, many AI topics are being rushed out and adding slash commands and other small things are very small things to add once the foundation is there.
The model is usually so confused after a /compact I also prefer a /clear.
I set up my directives to maintain a work log for all work that I do. I instruct Claude Code to maintain a full log of the conversation, all commands executed including results, all failures as well as successes, all learnings and discoveries, as well as a plan/task list including details of what's next. When context is getting full, I do a /clear and start the new session by re-reading the work log and it is able to jump right back into action without confusion.
Work logs are great because the context becomes portable - you can share it between different tools or engineers and can persist the context for reuse later if needed.
The trick is to parametrize the /compact. Something like "/compact focus on the XZY, the next steps will be FOOBAR, and keep a high level summary of BARFOO"
That makes the compaction summary a lot more focused and useful.
I think both /compact and /clear are valuable / have their own use cases.
my small mental mode:
- really quick fix / need to go over board with context -> just /compact + continue pushing
- next phase -> ask for handover document or update worklog, and then send fresh one to new phase.
I notice when I'm getting close and I tell it how to document current state into an .md file. Then I hit /clear and @ the new file.
This is probably very similar to /compact except I have a lot of control over the resulting context and can edit it and /clear again and retry if I run into an issue.
Yeah I was initially excited here, but it feels more like a demonstration of what's possible rather than a working tool.
I found the interface very nice but quickly ran up against limitations on prompt length (it wasn't that long) for example. I am used to being able to give detailed instructions, or even paste in errors/tracebacks.
One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
I was somewhat surprised to find that Zed still doesn't have a way to add your own local autocomplete AI using something like Ollama. Something like Qwen 2.5 coder at a tiny 1.5b parameters will work just fine for the stuff that I want. It runs fast and works when I'm between internet connections too.
I'd also like to see a company like Zed allow me to buy a license of their autocomplete AI model to run locally rather than renting and running it on their servers.
I'd also pay for something in the 10-15b parameter range that used more limited training data focused almost entirely on programming documentation and books along with professional business writing. Something with the coding knowledge of Qwen Coder combined with the professionalism and predictability of IBM Granite 3. I'd pay quite a lot for such an agent (especially if it got updates every couple of months that worked in new documentation, bugfixes, github threads, etc to keep the answers up-to-date).
> I'd also pay for something in the 10-15b parameter range that used more limited training data focused almost entirely on programming documentation and books along with professional business writing.
Unfortunately, pretraining on a lot of data (~everything they can get their hands on) is needed to give current LLMs their "intelligence" (for whatever definition of intelligence). Using less training data doesn't work as well for now. There definitely not enough programming and business writing to train a good model only on that.
If the LLM isn’t getting its data about coding projects from those projects and their surrounding documentation and tutorials, what is it going to train with?
Maybe it also needs some amount of other training data for basic speech patterns, but I’d again show IBM Granite as an example that professional and to-the-point LLMs are possible.
I use Cursor solely for the agent mode and do all my editing in an proper IDE, meaning Jetbrains products.
I genuinely don't understand why one would want to AI autocomplete. Deterministic autocomplete is amazing but AI autocomplete completely breaks my flow. Even just the few seconds of lag absolutely drive me nuts and then it often it is close to what I wanted but not exactly what I wanted. Either I am in control or the generative AI but mixing both feels so wrong.
I am happy people find use for the autocomplete but ugh I really don't get how they can stomach it. Maybe it is for people that are not good at typing or something.
Same sentiment for me. I barely use the agent, but love their autocomplete. Though I sometimes hear people say that GH Copilot has largely caught up on this front. Can anyone speak to that? I haven’t compared them recently.
If performance were equal, I’d strongly consider going back to GH Copilot just because I don’t love my main IDE being a fork. I occasionally encounter IDE-level bugs in Cursor that are unrelated to the AI features. Perhaps they’re in the upstream as well, but I always wonder if a. there will be a delay in merging fixes or b. whether the fork is introducing new bugs. Just an inherent tradeoff I guess of forking a complex codebase.
They haven’t. They had time to catch up, but they didn’t. They recently switched their auto complete model from 4o-mini to 4.1-mini. It’s not smarter at predicting what you are trying to do. Nothing magical like last year experience on Cursor (I haven’t tested lately, so it might be even better now).
I heard Windsurf is quite good and the closest to Cursor magic, available on Windsurf free plan (unlimited autocomplete). I should give that a try.
They plan to allow defining your own endpoint for auto-complete soon and when they do switching to a better model like Sonnet or a fine tune should beat Cursor
I don't know, I think it's a tie. I can have the agent do some busy work or refactoring while I'm writing code with the autocomplete. I can tell it how I want a file split up or how I want stuff changed, and tell it that I'll be making other changes and where. It's smart enough to ignore me and my work while it keeps itself busy with another task. Sort of the best of both worlds. Right now I have it replacing DraftJS with another library while I'm working on some feature requests.
I feel like this is the big divide, some people have no use for agents and swear by autocomplete. Others find the autocomplete a little annoying/not that useful and swear by agents.
For me my aha moment came with Claude Code and Sonnet 4. Before that AI coding was more of a novelty than actually useful.
I have recently been using Zed much more than cursor. However, the autocomplete is literally the only thing missing, and when dealing with refactors or code with tons of boilerplate, its just unbeatable. Eagerly awaiting a better autocomplete model and I can finally ditch Cursor.
I agree. I used to use vscode, then switched to Zed and used it for over a year (without AI). In February of this year, I started using Cursor to try out the AI features and I realised I really hated vscode now. Once Zed shipped agent mode, I switched back, and haven’t looked back. I very strongly never want to use vscode again.
I'm in the same boat but a neovim/cursor user. I desperately wish there was a package I could use in nvim that matched the multiline, file-aware autocomplete feature of Cursor. Of course I've tried supermaven, copilot etc, but I've only ever gotten those to work as in-line completions. They can do multiline but only from where my cursor is. What I love about Cursor is that I can spam tab and make a quick change across a whole file. Plus its suggestions are far faster and far better than the alternative.
That said, vscode's UX sucks ass to me. I believe it's the best UX for people that want a "good enough and just works" editor, but I'm an emacs/vim (yes both) guy and I don't like taking my hands off the keyboard ever. Vscode just doesn't have a good keyboard only workflow with vim bindings like emacs and nvim do.
its a bad anti-pattern that trades developer convenience for performance, UX etc. Its fair to hate on it
With the advent of coding agents, I really hope we see devs move away - back to the traditional approach of using native frameworks/languages as now, you can write for 1 platform and easily task AI to handle other platforms.
This will never happen and it's a bizarre, legacy fantasy, borne of a fixed imaginary ideal of what computing should
be. Programming will continue to move in the direction of ease-of-use and every time I see an out-of-topic reference to Electron in this forum I feel insane, like I'm fighting upstream. You will not see this - you will see more Electron apps, because that is the modern way of building cross-platform apps, and if you genuinely don't understand why that is I don't know how to explain it to you. You won't see another version of those because nobody is going to waste their time building cross-platform native apps
at a native layer to performatively impress posters on HN. You, and seemingly everybody else on HN, can continue to pretend that devex doesn't matter, but that's the difference I guess between caring about devex and shipping products.
It's not out of topic. We're discussing the Zed editor. Their whole marketing ploy is "we are not electron", "we are rust", "we are native", "we are not slow" alternative to VScode.
This is literally their whole distinguishing feature and people are switching because of it and just it.
It is! If the thing runs like shit, say it runs like shit. Say it's native or not, like every topic title and comment on HN until we weep of boredom. I know it's rust! everything is rust here! Is there any other reason I should care? Are we a forum for discussing interesting technology or are we a forum for discussing alternatives to VSCode? And again, who is switching? People shipping products or HN posters with their dumb metrics?
People who install zed are switching. I don't understand what you're trying to "get" at. You're complaining about people talking about Zed in a topic about Zed.
Zed seems to have been hugely succesful recently and their only real distinguishing feature is "fast from the ground up". It has less features than vscode. Worse AI features than Cursor. but people seem to love it nonetheless.
Turns out there is a market for people fed up with VScode-derivatives.
Cross platform application development is cool but the guys who made Zed are the guys who made Atom are the guys who made Electron, and they pointed out that long term the devex sucks and that Electron simply isn't a good platform for native applications that need any kind of memory control or similar features: https://zed.dev/blog/we-have-to-start-over
> My experience in Atom always felt like bending over backwards to try to achieve something that in principle should have been simple. Lay out some lines and read the position of the cursor at this spot in between these two characters. That seems fundamentally doable and yet it always felt like the tools were not at our disposal. They were very far away from what we wanted to do.
> Nathan: It was a nightmare. I mean, the ironic thing is that we created Electron to create Atom, but I can't imagine a worse application for Electron than a code editor, I don't know. For something simpler, it's probably fine, the memory footprint sucks, but it's fine. But for a code editor you just don't have the level of control I think you need to do these things in a straightforward way at the very least. It's always some... backflip.
Thinking Javascript was a language meant for desktop applications is what is insane - even more so than the convenience of using it, which is comparatively less insane.
I find Zed has some really frustrating UX choices. I’ll run an operation and it will either fail quietly, or be running in the background for a while with no indication that it is doing so.
It does have extensions, but they are much more limited. In particular they can't define UI elements inside buffers, so you can't replicate something with rich UI like the Git integration in an extension.
Does it really? At the end of the day i need it to do my job. Ideal values don’t help me doing my job. So i choose the editor best suited and the features i need. And that’s not zed at the moment.
There's an analogue here with programming language iteration— Python, Ruby and friends showed what the semantics were that were needed, and then a decade or two later, Go and Rust took those semantics and put them in compiled, performance-oriented languages.
Electron has been a powerful tool for quickly iterating UIs and plugin architectures in VSCode, Brackets, Atom, etc, now the window is open for a modern editor to deliver that experience without the massive memory footprint and UI stalls.
I agree with the main point but I am on battery often and the difference between native vs. one or multiple Electron apps in "doing my job" is easily several hours lost to battery life or interruptions for charging. Not a huge deal, but it's not my ideals that make me frown at charge cycles occurring twice as often.
This is simply not true… that’s the problem. As much as I like Zed, using it for the sake of not being an electron app doesn’t make any sense when Cursor’s edit prediction adds so much value. I’m not starved of resources and can run Cursor just fine – as far as Electron apps go VS Code is great, performant enough. I value productivity. I’ll very happily drop Cursor for Zed the second edit prediction is comparable. I’m eagerly waiting.
I wonder if Augment [1] are working on a Zed plugin.
I've been using Augment for more than a year in Jetbrains IDEs, and been very impressed by it, both the autocomplete and the Cursor-style agent. I've looked at Cursor and couldn't figure out why anyone needed to use a dedicated IDE when Augment exists as a plugin. Colleagues who have used Cursor have switched to Augment and say it's better.
Seems to me like Augment is an AI tool flying under most people's radar; not sure why it's not all over Hacker News.
I like autocomplete when it used to be a bit slower and only act on tab.
Right now it's borderline impossible to write code, the autocompletion results are loaded ultra fast and Cursor maps different buttons to autocompleting functionality.
It's no longer usable for me.
I'm fine getting autocompletes, but I decide when to trigger it, ideally after reading it, like this I can't even type.
>One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
It's not only the autocomplete. I've never had any issue with Cursor while Zed panicked, crashed and behaved inconsistently often (the login indicator would flicker between states while you were logged in and vice versa, clicking some menus would crash it and similar annoyances). Another strange thing I've observed is the reminder in the UI that rating an AI prompt would send your _entire chat history_ to Zed, which might be a major red flag for many people. One could accidentally rate it without being aware of that and then Zed has access to large and potentially sensitive parts of your company's code - I can't imagine any company being happy with that.
There are plenty of great VCs out there, going with Sequoia will definitely come with some unpleasant late consequences.
>This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
There are many "real competitors" to Cursor, like Windsurf, (Neo-)Vim, Helix, Emacs, Jetbrains. It's also worth being aware that not everybody is too excited about letting AI slop be the dominant part of their work. Some people prefer sprinkling a little AI here and there, instead of letting it do pretty much everything.
"even pulling up a file via search is more accurate in Cursor"
Huh? it takes it sometimes like 40s to find some file with the fuzzy search for me. In that time im going to the terminal running a "find" command with lots of * before I get some result in cursor
I want to try Zed but the Helix mode seems quite young. Vim mode sounds good, but i just can't move away from Helix mode. (oh and of course, my own modifications to Helix's input config)
My difficulty in finding editors that fit my desired input scheme kinda reminds me of the old pre-LSP days. Where you'd chose an editor based on it's language features. I wonder if we need some sort of common editor interface to allow these sort of text editing primitives to work in new editors, as it seems to be considerable friction.
I agree, I've fantasized about an editor with a truly pluggable editing model which is decoupled from the other parts.
Yi was kind of designed like this, I believe. You could compile in an emacs-like model, a vim-like model, or presumably make your own model.
I've used Helix and Kakoune in addition to Emacs and Vim, but dealing with the limitations/featureset/plugin treadmill gets a little tiring.
I have been following Zed, and it seems that they have rearchitected things to enable adding Helix mode and making the editing model a bit more modular, but it's still fairly new. They are fixing bugs pretty quickly. I will have to try it again.
I prefered Kakoune to Helix (it was more consistent). But to your point, being able to swap these things out more easily would let you choose an editor based on features, and not tradeoff between features and an ergonomic editing model.
Ironically you can use Ki inside of VSCode (and I know you can use Vim that way too), but VSCode is so darn bloated and slow...
The truly pluggable editor is emacs.
I too spent months trying out neovim, then emacs, then finding helix. Spent a year on helix, then zed because I would rather have something more complete, and brought with me all i could of helix modal editing.
But emacs. Emacs is the one that can truly become anything you like. And with lsp and treesitter being finally in it. I've finally came to my senses and started building my helix in it.
It’s exciting that Zed even has a Helix mode. That was a big moment for Helix.
Last time I tried it, though, I immediately ran into parts of the keymap that hadn’t been translated yet. I’m already at my limit of tools in beta mode/built from my own fork, so I switched back to Vim mode – where the team is on record explaining their thorough testing methodology.
As a Helix user of two years, I sometimes wonder if I actually like the Helix keymap (certainly some parts are nicer than Vim’s) or if I simply tolerate it because of how nice it is to get a polished TUI IDE out of the box. Either way, my muscle memory expects Helix mode now, rather than Vim.
Neovim can run in server mode, where other editors send it user input and then Neovim sends back the buffer. This is how I use vim in VSCode — not the Vim extension but the Neovim extension, which uses the real Neovim, which of course reads my Neovim config and plugins and makes them available to VSCode. So it seems like helix “just” needs a server mode, and then you can integrate it into any editor.
Helix seems to have good LSP support from what I can tell? The only language I use at $WORK that doesn't have full support is GraphQL which lacks auto indent.
If you want to try something similar to Helix in emacs, there's meow-mode. While I'm not a helix user myself, it shouldn't be too difficult to get meow to work like helix.
I thought the same, but I gave Helix a shot for fun a couple years ago and never looked back. It really does feel better/more ergonomic, but the greatest benefit is that almost everything you need is built in. I spent way too much time fiddling with Vim and NeoVim configs.
For me, definitely. Plus it's quite the muscle memory switch. I switched to Kakoune ages ago, and then eventually Helix because i liked its design a bit more.
I had the exact same problem. I was so stoked to try helix mode and then realized it obviously doesn’t have any of my backspace shortcuts. Duh, but still… back to helix!
I like Zed in concept.
I like Zed in the architectural and foundational aspects.
I want more tools like Zed to exist.
But, I find Zed challenging to adopt due to random nuances. First, settings management is a mixed bag and sometimes I just want a quick way to open the "settings.json" from the settings pane without fussing around. Then I'd like the "settings.json" to stay open (reopen) on a restart of Zed. Then I'd like the ability to use an LLM that doesn't have native tool calling support, which Zed seems to be the only app I've used that doesn't have a workaround. Then I'd like the UI to be a little easier to navigate as a new user, it feels a bit scattered and overwhelming at times.
I haven't used Zed much and I may give it another shot (soon), but it very much feels like a tool built by engineers for engineers... Which is great for power users, but seems not so great for new adopters.
I don't think the shortcomings are a blocker, but they are the reason I haven't adopted Zed. The shortcomings are just enough for me to take a step back and say "maybe I'll try again later".
I spent a while trying to set it up, as I share your general take on their ethos. Personally, I'm okay with a 'power user'-focused text editor, even! But the relative lack of syntax highlighting options got me to give up. Maybe I'm just spoiled from SublimeText's dope, complex, extensible system for specifying "contexts" in themes, but Zed was just nowhere near enough for me.
The keybinding system is also nuts if you turn on Vim mode, but I think I'd eventually get used to that. But functions need to be a different color than arguments, which need to be a different color than local variables... Just non-negotiable.
I look forward to trying it again sometime soon! The AI features seem rad, this included.
Zed does have a way to run LLMs without tool calling. From the agent pane, in the menu, select “new text thread”. I believe there’s a keyboard shortcut but I’m on my phone right now.
I'll take another look but from what I perceived all attempts to start a thread included tool calling in the payload.
I couldn't seem to get any message through without tool calling instructions in the payload. What you're describing sounds exactly like what I attempted.
I tried something like over 6 different variations of model configs with restarts of Zed in-between. The documentation and what Zed tries to configure are different as well. The fields don't match up with the built in type checking. I tried "openai" with the endpoint configured, "openai_compatible", and even "openrouter" hoping the REST signatures would be match well enough. Each configured with various fields to turn tool calling off and every single request that hit the REST server had tool calling.
Text threads include no tooling. They are plain markdown texts you can freely edit (including llm's responses) so you can fix small stuff yourself without annoying, context-polluting back and forths with the llm, at the potential cost of possible caching optimisations.
That's unfortunate. I use Zed and I'm moving towards containerising my dev environment (using SSH remote dev to connect Zed to the container) because all this agentic stuff seems like a security nightmare. At the very least I want to restrict the blast radius to my repos dir.
I would give them a week or less to support this. They've been improving the debugger so fast, it will take them no time to support remote claude code connections.
Remote dev isn't very good in Zed, unfortunately. For some reason they chose not to apply the local editor's settings to a remote session by default. Every remote has its own config file. Questionable choice, imo
IIRC it doesn’t work in Cursor either, and their own AI sidebar was getting weird issues too. Mostly switched back to VSCode for SSH workflows because of that.
Really love Zed after working in it full time for a month now and pay their 20$ sub tier to support them even when I rarely use the LLM integration beyond the auto-complete.
At first I was very dismissive of it due to being Apple-first but they've turned it around with really good Linux support and it seems like Windows soon as well!
Also love Zed, but sigh, it's VC funded. We all know how this is going to end. Best VIM mode ever implemented in a (non vim) app. I use it as my 2nd editor (most of the time in Jetbrains products).
I just hope I'm wrong about the medium term impact of the VC funding but rushing AI AI AI out seems to be a sign of that rather than fixing fundamental issues that remain such as the ugly font rendering.
Agreed, though being OS is no panacea as we have seen from countless other projects, but it does mitigate some concern of investing in an editor and its ecosystem and getting rugpulled.
This interests me but they don't address practical Claude Code Opus 4.1 use at scale.
I have a $200/month Anthropic Max subscription that I use for help in exploring and coding my math research. As of now no AI model can compete with Opus 4.1 for helping me with my most challenging tasks. I try every one I can. Gemini 2.5 Pro is great for code review and a second opinion, but drives off the road when it takes the wheel.
I tried a $100/monthly plan and spent $20 in an hour the first time I went over; an API key is not a practical way to use Opus 4.1.
There are plenty of concerns using Clause Code in a terminal, that Zed could address. Mainly, I can't "see over AI's shoulder" so I need to also test. The most careful extension I coded was terminal sessions we could share as equal participants. Nevertheless, as a rule I'd attribute my relative success to just living with shortcomings, as if a "partner that snores". AI loses track of the current directory all the time, or forgets my variable naming and comment conventions? Just keep going, fix it later.
How can I get equivalent value to my Max plan, using Claude Code Opus 4.1 with Zed?
I use zed and claude code side by side right now.
I haven't tried out the newly released assisted agent mode with Zed.
Yes Opus has been good with instruction following and same with Gemini for 2nd opinions and brainstorming.
They're not perfect but definitely I see plenty of value in both tools as far as they are reliable services.
I don't like the cloud based functioning of the models as the experience is extremely flaky and not reliable.
I've gound OpenAI Codex and the models in codex too be more reliable in responses and consistency of the quality service.
I would still prefer to have a fully locally hosted equivalent of what ever the state of the art coding assisstant models to speed up work.
That will take time though as in with every technological evolution.
We will be stuck with time sharing for sometime haha. Until the resource aspect of this technology scales and economizes to become ubiquitous.
Maybe there's a way to use your Max plan? I heard OpenAI works the same way, there's a way to use the codex cli with your chatgpt subscription (I think it gives it a jwt token or something). There are 3rd party tools that can then use the same token to make API requests via the subscription, instead of via API billing. (Which is sort of allowed, since the cli is open source?)
I'm guessing claude code works roughly the same way?
Their landing page via Safari manages to crash my iPhone 11 Pro repeatedly, namely crashing Safari but also another app and the Bluetooth connections - had not seen that before so they are clearly innovative.
Honestly, I’d love to know why that happens. Can you take a look at the logs? On Mac, you can do it through the Console app, and on Linux, through idevicesyslog.
Zed is so great, I do wish they would focus just a little bit more on bringing the UI just a bit more up to parity with VS Code, I would switch full time.
Running on Linux here. Working great for me. If you are referring to font rendering, unfortunately the Rust ecosystem for it is still young, so there are improvements to be made.
Do people really need that with modern computers? My computer is 10 years old and I just restarted VS in the last project I was working on. It was about 4-5 seconds before I could edit the text, which doesn't seem long. And I have 17GB available memory. Anyway it doesn't matter because I just don't restart VSCode that much. I do open projects in new windows and those can get slow, but the slow ones are mostly just rust code with rust-analyzer overhead, and when dealing with rust, slow-opening projects are only the beginning.
I don't know, it feels like Zed popularity is just people chasing the latest editor hotness, a time-honored traditional programmer ritual to be sure, but still, just a ritual. And now it seems zed devs have to put AI in front of all other initiatives, probably because of the VC funding they took.
I could see not wanting to use VSCode for other reasons, like MS pivoting back to "be evil", but at least in my little bubble, performance is not one of them.
I tried Zed several times and I just don't see the point.
The main issues with VScode over something like the Jetbrains IDEs is that language servers are just not as powerful or as integrated to the IDE as the Jetbrains solution can be and Zed does nothing to solve it.
I don't think it being a native app offers much added value.
Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow. Emacs starts up faster than an empty Zed window, unfortunately. It is still way faster than IntelliJ but comparing it to that is a low bar.
VSCodium starts up faster for me than Zed which I compiled yesterday with release mode. Here I am referring to the time spent just on waiting for the window to start up, not the extensions and all that I am using with VSCodium, that takes time. I wonder why this is, that VSCodium shows the window quicker than Zed.
Regardless, I will give Zed a try with Go development. I assume Zed has extensions, too? Are there any extensions for Go? If so, I might replace VSCodium with Zed but only if it has similar features to VSCodium. If not, I will stick to VSCodium as there is no reason for me to change.
I'm not a Zed developer, but I'm pretty sure LSP interfaces are pretty much standardized now, in large part to VS Code's efforts, so they're pretty consistent across most editors that support them.
That doesn't mean Zed will have all the other extensions that VS Code has... Recently added the new SQL Server extension(s) and it's been at least interesting, in a way slightly better than using SMMS. It's pretty much burrowing the UI from Azure Data Studio (or whatever it was called). Haven't tried similar for PG/SQLite etc yet.
It’s built by the team that built atom which was way better than vscode but was mothballed when Microsoft bought GitHub.
They built it from scratch and not on electron bloat so it is a much better foundation. It will take a long time to reach parity with vscode but when it does it will smoke it.
I think you do not understand the value proposition of Zed.
It is an editor made for people who are used to double-clicking individual files rather than opening a folder in VS Code, so they close and open their editor dozens or even hundreds of times per day.
Let's say VS Code takes 5 seconds to boot.
Some programmers may argue: "yes, I spend 3 hours on a project or just leave it open overnight, so 5 seconds per week is nothing"
But here is not the case, it is for programmers who come from Notepad/Sublime/Notepad++/emacs/vi, and who opens a single file and closes the editor right after.
If you work 2 hours, maybe 4 files per minute, this means 120 * 4 openings = 480 openings.
It means you would have wasted 2400 seconds (40 minutes per day!) waiting for VS Code to open (about 33% of the 2-hour work session spent waiting)
Yes, like with Notepad or Zed, you lose some features like Colors or Syntax checking, but still, time is the most precious thing in life.
If you think "build by atom team" and "not electron" are any kind of serious advantage for any peace of software than your are the one who lacks knowledge about software development.
It would be relevant that they were the team behind Atom if they seemed to understand the lessons of Atom...
Instead of learning from what worked and fixing what didn't, they just threw everything away and wandered off in some totally different direction. They did the reactionary kind of learning instead of the theory-building kind: https://xkcd.com/242/
It is new and is talked about a lot on HN and Reddit. And it is not developed by Big Bad Corporation, instead it is developed by Good VC-backed Startup.
In this demographics, hype rarely is connected to technical qualities, they are used more as a post-hoc rationalization.
That figures, their lead platform was the Mac where HiDPI is totally ubiquitous, so their renderer probably has no provisions for subpixel font rendering.
While I do not doubt that there are people who experience this on some monitor/OS combinations, I have used zed on basic 1080p and 1440p 24" monitors with no issue. Sometimes I have general issues with some monitors in macos, which is usually due to some super-resolution/sharpness setting on the monitor itself that I need to adjust, but nothing specific to zed. All I say is that these issues are far from universal with non-hidpi monitors.
As I said, I do notice when it is blurry, and in such a case it is a problem with anything that is rendered on that monitor not just zed. As I said, this does not happen "on any monitor" that is not hidpi. I use multiple operating systems on my day to day work, so I am not as brainwashed by apple as to not notice when such rendering issues arise.
I know some people have bad experiences with 1440p and macos for some reason, but I haven't had any such experience that I could not fix. So all these are not universal. Some people act as if any monitor below 200dpi will look terrible on macsos. This is definitely not the case.
Other operating systems have three times the horizontal resolution when rendering fonts. It’s simply not possible to fix it on macOS because they removed subpixel rendering. It’s absolutely true that macOS fonts look substantially more blurry than fonts on other operating systems that implement subpixel rendering when you’re using a 1440p monitor.
This discussion goes back twenty years, with Apple going for preserving the original typeface appearance over crispness. It depends what you value the most and is entirely subjective.
1) How much font hinting to apply. More hinting changes the shape to make glyphs line up better with pixels so that less antialiasing is required. macOS prefers very light hinting to preserve shapes at the cost of blurriness. This is what you are talking about.
2) Subpixel rendering. This effectively triples the horizontal resolution when rendering fonts, and does not affect the shape at all. Fonts look dramatically better on normal dpi displays when using it. macOS removed support for this many years ago. This is what I'm talking about.
While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.
My guess: their shaders or text rendering don't account for sub-pixel anti-aliasing, which is critical to getting decent text rendering on low pixel density displays.
If they'd used Skia (which is what Electron and Chromium use), they would've got this for free. Instead they tried to reinvent the world and didn't realise how big the world was.
As far as I can figure out, the root issue is even simpler than that. Their hinter is broken. The edges of characters aren't aligned with the pixel grid, so there's lots of fuzzy/blurry looking text.
I love how we just reinvent the wheel again, and again, and again, and again...
MacOS native apps have had great sub-pixel rendering all along, but I guess since we have to develop everything in Electron now it's time to reimplement all the exiting functionality.
> MacOS native apps have had great sub-pixel rendering all along
Apple removed subpixel anti-aliasing in Mojave, seven years ago, because it's not necessary on the HiDPI/Retina displays they ship as standard. They still do greyscale anti-aliasing but that's not the same thing as subpixel.
> because it's not necessary on the HiDPI/Retina displays they ship as standard.
I disagree. Subpixel anti-aliasing triples the available horizontal resolution, and makes text crisper. The algorithms are known and regardless of the density it should always be applied to text and vector graphics elements.
The RGB stripe layout is so useful that OLED manufacturers are moving to it in 2026, away from the long-derided PenTile where magenta/green fringing is seen even on the densest displays.
In fact rendering on macOS is completely broken, and I don't know how people stand by it. At any scaling factor selected that is not a perfect factor of the actual hardware resolution (the 'looks like' value in Settings), the final framebuffer is scaled and interpolated to the display resolution, and everything is noticeably more blurry.
Windows has had some form of hardware-independent rendering since Windows 7, and proper pixel density control arrived in Windows 8.
Subpixel rendering is effective but it's also a massive pain in the ass to maintain, especially if you want to take full advantage of the GPU. Microsoft has kept it around for much longer but even they are steadily moving away, bits and pieces of the Win11 UI render with greyscale AA regardless of system settings because their newer GUI toolkits don't even attempt to support subpixel fonts.
That said, for something like a text editor where fonts are central the entire application and the worst subpixel edge cases like animation are unlikely to come up, it's maybe not unreasonable to ask them to go the extra mile. It's going to be a sticking point on Windows and Linux for a long time if they don't.
Top of my head switching between IntelliJ and Zed:
- Git UI is extremely barebones with no support for other VCS
- No merge tool or side-by-side diffs
- Configuration is all JSON
- Would be nice having a full file tree for the search editor instead of just the list; having the functionality split between a tab and the outline panel is quite clunky.
- Ability to move panels (files/git/console/debugger/etc) into standalone windows or other configurations (multiple docks per side, multiple copies of the same panel linked to a specific tab).
Zed is basically a slightly more featured text editor, so it does a good job when I just want to open something quickly and do small edits. So it's really replacing Sublime Text.
But I find myself hopping out to other tools when I'm using Zed which wasn't really common with IntelliJ. So I still want to use a proper IDE for proper development work.
Yeah, no, I tried that thinking it was going to be the JetBrains merge as a standalone product and it simply does not have the three-way sauce. Sublime doesn't even offer any way I can view a live base->left or base->right view as I do the merge does it?
Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
> Ability to move panels (files/git/console/debugger/etc) into standalone windows
Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
> Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
Really just a GUI for editing, the storage format can still be JSON and synced/backed up however you handle text files.
It just really nice having settings grouped by categories, with dropdowns for possible values, indicators for changes from default values or values overridden by project settings, search/hide/filters, and tooltips for what it does.
Right now the experience with Zed is: open the settings file, open the default settings file for documentation, and basically use search and copy-paste magic value strings/int/float/nulls into the right nested object/key.
> Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
Really the separate window experience (including the file browser/git pane). Really nice having the git panel just open on a window so you can quickly glance at changed files and quickly jump back to them for more editing. Or having search results able to spawn tabs in another pane/window so you don't have to keep switching back to search or rearranging the tab after opening the file from it.
Or even just expanding the workspace across monitors. Right now you can't even move tabs into its own window or across windows.
Yes, a GUI for settings is nice if only for one thing: so there can be a search box that you can use to search over all the settings to find what you need in a pinch. It's a lot friendlier if I can do something like "Open Settings > Ctrl+F > 'Font'" or whatever than having to go find the manual and look it up.
I don't care about the configuration language so much personally (though JSON is of course pretty lame in a lot of ways for that task.)
People are bringing up a lot of sophisticated stuff. Honestly for me it would just be a more flexible panel system that lets me see eg: File Explorer, Git UI, AI mode, etc, all at the same time.
I can’t really pin down the reason but somehow vscode just feels a bit more „balanced“ to me - the font sizes, little borders, icons and details, it’s more consistent.
Git: IntelliJ is miles ahead. And we’re talking about essential features like three-may merge panel, diffing 2 files, diffing same file between branches, diffing folders, etc
Tests:. Zed is bare bones compared to IntelliJ (rerun failed tests, export list of failures, go to failed lines easily etc
The AI stuff is cool but it won’t get me to switch from PyCharm.
Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance. Zed is one of the fastest programs i use. I used to laugh when seeing them market fps and such, but yeesh it's fast
> I found Copilot tab completion completion to be VERY slow in Zed, for some reason.
> Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow
> I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code.
> I mean, good AI tab completion feels like a super power. Zed’s is not that good. It’s slow and normally not at all what I want.
> Zed tab is a lot worse in comparison (partly because it’s slow)
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).
> All I'm saying is that contrary to what someone else said about the software being "fast" I tried it and at startup, it was unusably slow.
> Tried using zed on Linux (pop os, Nvidia) several months ago, was terribly slow, ~1s to open right click context window.
> Zed is as close as it gets, I also use it, but it is still slow and cumbersome sometimes.
I'll stop here. There are other 4 pages of comments to pick anecdotes from, in this simple search alone.
It is a feature that they control. Whether it comes from the model, a bad prompt, a bad provider or a bug in their implementation is their responsibility (especially considering you have to pay per-request AI features).
There are tons of complains about zed performance there.
Do you think messages like this are talking about VSCode performance?
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).
Smoothness and frames per second is the core of why they were building a very optimized editor. Not sure if it is just your machine that it is not leveraging the right bits.
For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.
This could be an issue with GPU drivers. I experienced some incompatibility with GPU kernel drivers that allowed Zed to crash the whole window manager during text selection.
There's a reason everyone writes their GUI apps in Electron nowadays. Browser have spent 30 years figuring out fast rendering, it's hard to beat that, even with native code.
I have no idea what they're talking about. Maybe they're used to a smooth scroll animation in VS Code or something? Zed feels snappier/lighter in just about every way to me.
No kidding. It is /so/ fast. It has remote development like VS Code, and most of the features I use, so it's my main thing now. Claude Code was the only thing that made me wince, since I wondered if I was living in the dark ages. VS Code of course has many more extensions, but I don't use that many.
What most of these comments are missing is the attempt at standardization and unification.
There are a lot of comments that people need X feature in order to switch to Y editor. While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.
It appears that our industry is moving towards adoption, sometimes mandatory, of AI coding agents. Regardless of your feelings on the topic, having good tooling to support this effort comes down to: switching costs, compatibility with existing editors, and a strong ecosystem of third party extensions.
While Cursor/Windsurf jumped the gun on bespoke editor integrations with LLMs - the adoption of MCP and other SDKs for coding agents means it's plug and play. The full feature set will be in every editor connected to every agent.
I think Zed wins on having the lowest switching costs for most developers. Paying down generic solutions like Agent Client Protocol (AC) now is a good strategy. It took multiple parties coming together for us to get TLS, OAuth 2.0, and ECMAScript.
I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).
> I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).
This is such a poor analogy. Yes, a good chef can make do with a different knife, but there is a reason why chefs pay for significantly higher quality knives, keep them sharpened, and treat them with diligence and care, than other kitchen tools. A blunt knife can actually be dangerous. Consequently, a lot of chefs buy knives that are effectively hand crafted / forged knives out of this relentless pursuit of quality.
> What most of these comments are missing is the attempt at standardization and unification.
> While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.
I think your general perception is not something I agree with. I want to use software I enjoy using. Programming is a creative exercise for me, and I want to use the tools I enjoy. If a tool is not enjoyable to use, I do not want to use it. Sometimes, productivity does increase enjoyment, but sometimes it doesn't. For example, arguably I would have been more productive in my Java days if I used Eclipse, but because the editor was so bad, I preferred to learn the APIs myself and use Sublime Text instead.
I also don't think I'm sympathetic to the survival of any particular editor. Software comes and goes, and sustainably built business models will prevail. All of the AI-first editors hinge on this being the right iteration of this technology, and we simply do not have a long enough timeframe or context to know if this is truly the best way to write code using AI. MCP/ACP, whatever else might be the best strategy for now, but I think it's too early for anyone to suggest that we've come to the right conclusion forever.
As someone who is in the position to see what the next really disruptive innovation is, you're quite right that there exist much, much better ways to write and collaborate on code. Flying leaps of innovation to Zed's tiny shuffle-steps.
Zed spent their innovation budget on Rust and GPUI, and as a result they have no energy to question the status quo of IDEs as a whole. Git and LSP are antiquated but form the bedrock of their plans for the future.
Essentially at this point they can only do spaghetti enigneering: adding more and more complexity on top of the complexity that already exists. IDEs have been through so many iterations of this process already that all the real wins are in refactoring: moving the whole system (and ecosystem) design sideways, which is he one thing they dare not try to do (though it happens to be my forte).
BABLR -- a parser framework, and agAST, the DOM structure at the heart of our state layer. Come to our Discord if you want to learn more. We're trying to launch in the next day or two here.
I'm sorry if this is blunt but is Agent Client Protocol... ...good?
It just looks to me like a bolted-on dongle to the past 50 years of kludges in editor design. It hasn't got 1/20th of the value proposition that a proper shared state layer would offer.
My main issue with claude code is running multiple ones in parallel. I don't want to manually do all the git worktree stuff, I just want claude to handle it for me.
So if Zed automatically handles that (where there's a worktree per thread) I can see the appeal. Apart from that, I'm already using Tower to view the changes so I'm not really sure what the value here is.
I tried installing it, and got an error "can't load supported slash commands" – not sure what that means.
It's great that Zed adding this very useful feature, but isn't this effectively cannibalize their own AI subscription plans? Why pay zed $20 when you already pay for claude code and can use it in the assistant panel? You might still want the edit prediction feature, but then why pay zed $20 when you can pay $10 github copilot and can use it to power zed's edit prediction feature?
It’s also great that they’re willing to risk that, in the name of a potentially better user experience. That’s what gets them to win in the long run, not building another walled garden.
I have been using zed a fair bit with clause api and the 50 free prompts a month that zed provide on the free plan works out to roughly $8 for an equivalent amount of code using the claude api.
But no idea how it compares to the subscription plan.
I am sure Zed is great and I appreciate the effort put in to create it, but nowadays I just cannot imagine switching from VSCode to something else. In my limited understanding, none of the existing alternatives offer anything (and often misses at least something) truly innovative or anything else that VSCode extension wouldn't solve. On VSCode I have about 15 different profiles setup, each with different settings and dozens of extensions based on either a technology stack or a project - it would be really difficult to find a good reason to throw it all away. The idea of switching between IDEs does not appeal to me either. I do use Neovim a little bit too, but most of that usage time was spent on configuration.
It's really interesting point of view. I'm one of those people who avoid using VSCode at any cost. It's slow, it's bloated, the UI is not great, and it's slowly being locked down by Microsoft.
If Zed would not exist, I would be using helix, neovim, or emacs as I did before.
VSCode is actually not slow. The problem is to make it useful you need to add quite a few extensions, and those can be slow. That itself wouldn't be too bad but VSCode doesn't expose any information about what is causing the slowness. You end up with "VSCode is slow and it could be due to any one of the dozen extensions I have installed", which effectively means that VSCode is slow.
It remains to be seen if Zed can avoid that though.
VSCode (and all Electron based editors) have undeniable input latency. Zed is built by the same team that developed Atom and Electron and one of their stated goals is to make up for the shortcomings of these technologies.
If you don't feel that VSCode is slow, it's because you are used to it.
> VSCode (and all Electron based editors) have undeniable input latency.
Start up time, sure. But VSCode was lauded as the first performant Electron based editor. I just tested VSCode, Zed, and vim and I can't see any difference from when I press a key to when a character shows up on the screen (appears instantly). I'd be curious to see the results of a blind test, and wonder if people's biases against Electron are showing up.
>If you don't feel that VSCode is slow, it's because you are used to it.
I don't think this is a fair claim. When you start doing an apples to apples comparison, that is to say make full use of IDE and auto-completion features it's difficult to see a difference given that the latency and speed of the plugins starts to dominate any millisecond difference in input latency or rendering speed.
No. When a press a character key on my keyboard, it should appear in my editor immediately. All other IDE features like auto-completion happen asynchronously.
> When a press a character key on my keyboard, it should appear in my editor immediately.
Seems to work the same for me in VSCode, CLion, and nvim. I don't doubt that you have issues with it (I've experienced slow editors & laggy input, it sucks) but I don't think it's inherent to VSCode. Doesn't mean it's not a bug, but if I had that issue I'd try with no extensions to verify, then binary search disabling the extensions I want until I find the one causing the lag.
>All other IDE features like auto-completion happen asynchronously
in the technical sense, but you as a developer don't use auto-completion asynchronously. It's not like you autocomplete and continue typing and then come back to the completion. When you complete at point you have wait. Whether that keypress takes 2 or 3 milliseconds isn't going to make a difference when the inter-process communication of your editor and its services is magnitudes slower. It's not like programming is like playing an FPS game. You're not in any meaningful sense limited by your mechanical input speed.
> Are you telling me that it was a delay when you type in vscode? If so, either your configuration or computer is doing something wrong
This is simply not true. There is inherent latency in any rendering pipeline, and VSCode and Atom both have input latency that is significantly higher than other editors like Sublime Text owing to a bloated rendering pipeline. You can read more about this and how easy it is to introduce latency simply by changing basic things like keyboards here: https://danluu.com/input-lag/ or editors specifically: https://pavelfatin.com/typing-with-pleasure/
vscode is noticeably slow compared to sublime text or zed, even without any extension. You instantly notice it when switching files or typing things that trigger auto-completions.
In the end the feeling is drastically different. It weirdly makes for a more peaceful experience to have such a snappy editor.
vscode wins thanks to all its extensions, where basically every language is supported and most features you can think of are there. But it's kinda like modern react. You know better alternatives exist, like solid or svelte, but the community is so big, it stays the easier choice in the end.
You can actually open the text tools on discord and see what's taking up memory and CPU.
They also have a new feature that's experimental that lets you offload extensions to a separate extension host so they don't block on the main thread for poorly designed or performing extensions.
I tried VSCode many times in my life and just hated the experience so much. It put me away from GUI editors for years, didn't want to try any of them. So ugly and so sluggish.
Zed was the first one that put me to rethink my position. It is so snappy on my Linux workstation and I don't have any issues with it's GUI. I finally switched from vim et.al.
But I know I have "weird" opinions, I also really dislike Apple products and their software.
I think a lot of people forget how long ago Electron/Atom were released, and the subsequent Cambrian explosion of Electron based apps and editors like VSCode. There's probably a huge amount of developers that haven't used anything else.
Ironically, I used JetBrains products for years before switching to VS Code because the latter felt so much faster. So it definitely depends on what you're used to.
Zed feels significantly faster than VS Code, but it also doesn't feel as polished and "complete" as an IDE, so I'm going to stick to VS Code for now for the same reason I stuck to JetBrains IDEs for so long.
Same here, still using Sublime Text due to its general snappiness, but can't wait for Zed to be released on Windows, it feels like a modern successor to ST that just keeps getting better.
Yeah it hooks into some blocking event that gets called on every keypress. At least that's how it worked last time I tried it many years ago. Very sluggish.
Fortunately standard editing shortcuts like Ctrl-D, Ctrl-left/right, etc. replace 99% of Vim "magic" and are way easier to remember and use.
I just opened the same project in Cursor and Zed and started typing around, and I can't tell any difference. I am usually very sensitive to this stuff; for example, I can detect when my Mac drops below 20% battery because ProMotion is disabled and the screen refresh rate drops to 60Hz.
This is why I cannot switch to neovim despite my attempts. I love the workflow, but the delay is too noticeable for me, and nothing helps. It's not a long delay, but long enough for me to feel like I have to wait for hours compared to Zed.
vscode started to intermittently freeze my whole desktop on arch linux recently. I rage deleted it. imho, it’s a valid compromise to choose a snappy lightweight editor over vscode with all available extensions.
sadly it reminds me of how visual studio used to be and and how much of a sluggish mess it is today. I don’t think the community can fix it either. it’s an uphill battle when MS is known to lose care as soon as they reach a critical mass of users.
VS Code is sluggish for me as well and crashes. I have minimal expansions, this is just a poor excuse for a lousy editor. Zed is much better, neovim is much better. My only real concern with Zed is what bait-and-switch is awaiting for us when they decide to make money. But it's a fantastic editor, no question about that.
There is always a "better mousetrap", and there are those that continue to use the old one because they "know how it works and it's set up just the way I like it". And there are others that try every new mousetrap that hits the market. (and that's ok, not slighting either one)
I will say that I personally have never really gelled with VSCode no matter how much I try to customize it, it still is just a bit off. For me, it's like it's too much to be a simple editor like SublimeText or NeoVim, but not quite enough to be an IDE like IntelliJ or Visual Studio (full). It does just enough that I expect a bit more of it and it often fails to deliver. Right now I tend to just use 2 editors - one very simple one for viewing/editing text files and one IDE (currently IntelliJ) for coding in a project.
On topic - Zed is actually a really nice editor. It had some rough edges last time I tried it, but it's probably about time to give it another go.
I wanted to like VSCode but it has enough input latency on my machines that it's not that enjoyable when I'm "locked in". Also if I'm running a bunch of services in Docker on MacOS (which means they're running VMs sigh) the overhead of VSCode is just too much and the system starts swapping constantly grinding the whole thing to a halt. I also find configuring it a pain. Every configuration pane feels ad-hoc and not part of a holistic, configurable system. Emacs has lots of crusty bits and an annoying event loop that you have to really work around but is designed a lot more holistically than VSCode.
Zed to me feels like a great batteries-included editor and I still run it as my non-emacs alternate editor. I wish its configuration was a bit more discoverable (especially with configuring linters/formatters), but it's 95% of what I need 95% of the time.
I had to use VSCode for some projects in the past because it was what was available on the clients workstations...
I can't imagine having to use that laggy electron abomination all the time. For me Zed is sent from heaven, because my previously preferred editor (geany) hast basically zero developtment nowadays.
I normally care a ton about latency and in the main project I work on I put extreme focus on reducing input latency in text input fields, but...
I've used VS Code for ages. I tried Zed. I don't really feel a difference. It's smoother but VS Code is more than smooth enough for me and has tons of features I rely on that don't exist in dev.
Meanwhile, when I tried Ghostty I noticed a significant improvement in "typefeel" compared to iTerm. So I'm not immune to detecting such a difference.
I mainly used VSCode on locked down corporate laptops. Usually good hardware but running windows and corporate security bloat.
But where I was allowed to install alternative editors they were snappy.
Zed succeeds at reducing the switching cost. I used NeoVim for ten years daily and configured it way back in college days.
I thought I would be unable to move to a GUI editor and it turns out that the speed and efficiency of Zed plus the almost one-to-one mapping of Vim features means that I am extremely productive in Zed.
I think the point of ACP being an open protocol is so that other editors (e.g. VSCode, Neovim) can implement it as a receiver and integration with ClaudeCode/GeminiCLI/... would just work.
OTOH I'd ten to prefer as less plugins as possible in VSCode, just because they are inherently dangerous, I'd like Zed plugins that are WASM, so they don't have access to the world.
But I agree that VSCode Typescript support is better than Zed, it works with weird projects setup, while Zed has more troubles. I at work VSCode and Zed/Helix for my projects, generally I use Zed when want to do some AI stuff, otherwise I just use Helix.
It sounds like you haven't tried Jetbrains IDEs. I understand still preferring VsCode in that case, but I think you would be saying "I prefer VsCode" vs "I don't see a reason". A big con with JB is they are very slow. The upside is that they manage multi-file projects, refactoring, and introspection far better than VsCode.
I switched to Neovim a year ago, and while I did spend a significant amount of time on configuring it, I haven't touched my config for months now - and I'm perfectly happy with it. There's things I can improve, but it does what I want.
I’m in the same boat. I spent a lot of nights for a couple weeks getting everything tuned just right, in the beginning. But now, several years later, it really doesn’t take much. I spend maybe 2-3 hours once every few months, and that’s usually just adding a bunch of features that sound nice to make my life better. I’ve easily gone 6+ months without touching neovim config, if not longer, because it’s unnecessary. It only matters if you want to further improve your editor
Glad to see this out so quickly. Like I said[0] on the Gemini announcement post, it feels like Zed is trying to get out of the business of iterating on agent logic and just let other people handle it. Any prompting secret sauce a) is trivial to copy, and b) gets eaten by the next model generation anyway. The capabilities of Claude Code, Codex, OpenCode, etc. seem to me to be converging.
Plausible take. My first time using a coding agent was with Zed’s. As a sceptic, I was blown away. Two or weeks later Claude Code dropped and I haven’t used the Zed agent since. I canceled my subscription because 20 EUR/month for AI features I no longer use felt silly. And with the massive investment from Sequoia, and the real possibility of enshittification, I couldn’t mentally classify it as a monthly ‘donation’ to sponsor ongoing development either.
That last part is just me maybe. But I’m sure they poured a lot of time into their (granted, very nice) agent, only for many users to switch to Claude shortly after release. Letting others build the agent but being the place where the agent get used seems like a smart move
Fine. Cool step for Zed to push ACP, and I think this is the right direction for the IDE space.
But tbh if it’s not as frictionless as the Codex IDE extension in a Zed-skinned VSCode, it doesn’t matter.
Tried giving Claude and CC many chances, but the cognitive load of constantly managing a hard context window is DOA.
Codex w/gpt-5 is on par if not better than any of Anthropic’s solutions at this point, and the ubiquity (web, CLI, IDE) + UX consistency of Codex under one account/plan just dominates any marginal value of using a different model at a higher price.
Codex just works. Then it keeps working. Then it keeps working.
Any solution that wants to compete with OAI’s latest hostile takeover attempt has to match then beat on “unlimited/anywhere/frictionless” UX across platforms AND price ($200/mo all in).
I don’t see a good way out of this for most, except through major spend on playing catchup.
Guess that’s why Anthropic just raised again. Cursor is clearly trying to play, but they will always be a markup product until they launch their own SOTA model. Is Gemini still alive?
If they could add support for remote development (meaning the claude code instance runs on the remote server in the same folder that you have already opened as a remote/ssh project in Zed) and add a way to paste images in Zed and have them interpreted by CC on the server, this would really be a killer feature.
As someone who’s running a development agency I need to have tens of dev environments for different client projects running at the same time, and being able to switch between them multiple times every day (often from multiple client computers), so a remote server is the only way to go–I don’t want all of that stuff running on my Macs.
Nowadays I also have tens of CCs running on the dev server, switching between them using tmux, which works great, but the lack of support for pasting images through the terminal/ssh/tmux has been a real bummer. It would be great if Zed found a way to bridge that gap.
As a VS Code + Claude Code user, I'm really excited to see progress here, because the official near-zero-config Claude Code IDE integration is... inflexible, at best.
What if I want to send a subset of my open editor panes to Claude Code? What if I want Claude Code to open diffs for its edited files in a specific area/window, and silently open that file so that I can multitask on other things without it taking focus when it's done thinking? What if I want keyboard shortcuts for specific slash commands, or to trigger a slash command from another task?
Having a robust open-source ecosystem that will let users fork and build customizable UI around coding agent experiences will make them even better, and the space will move even more quickly because the ecosystem won't split between different preferences for agent/model choice. It's an incredible time to be coding.
Ah, if it is using the SDK, that is a big limitation. The SDK is nice, but it is meant to provide support for backend use of Claude Code, not integrating an interactive session.
This might come off as a naive question so pardon me in advance for my ignorance. I got Claude Max just last week and I have been using it in the MacOS Terminal app. I also used it in Zed and VS Code terminals and faced no issues. So what is the advantage of using it natively like this?
It's interesting that VSCode has its own Claude code extension which works well and does most of this.
Zed has a lot of these micro-battles ahead where it has to spend money building solutions that VSCode's community shipped without their core team putting in any effort at all.
Zed has really good vim bindings + mix of native shortcuts making a powerful workflow. The window management keyboard shortcuts are great and is the main reason I switched from some vscode use. Its kind of what I wanted neovim + tmux to be with less work and setup.
Zed doesn’t have file delete undo and I found the AI autocomplete to be so bad I had to turn it off. I still use vscode for work. Zed is kind of in a purgatory state where its lacking in way to be a main for many folks but its close. Just the AI focus is sadly the best way for it to keep investments going, but are really not the top things I think Zed needs.
Naive question: is using Claude Code from the command line or in these tools like VSC or Zed different from using it in the native app on a desktop? Is that because it has access to your codebase?
After having troubles with Claude desktop not properly updating canvas document, I found that apparently Claude Code is same as desktop one plus you can use it not just for code but documents in VS Code.
In Elixir/Rails (and newly React) world you can connect Clade Desktop to Tidewave, which gives you pretty close integration with codebase and CLI tools. That makes the experience somewhat similar to running Claude Code in editor's terminal, or now directly connected in Zed.
I think basically all these tools are trying to integrate all the stuff together and find the best way to do that, so that you don't need to be copy-pasting stuff around, jumping between tools, etc.
Not tried with Zed yet, but in VS Code it's mostly the same except you can view the diffs in the editor, and can give context from the open file. I think it can also see errors from the editor.
I wish the release notes of Zed would contain less AI.*, and more focus on getting the core editor capabilities completed. I'm a fan though, don't get me wrong.
There is a Windows version if you're willing to use unofficial builds. I've been using it successfully for a few weeks. There's a few more rough corners than in the official Mac/Linux version, but it's usable.
Really excited for this. I'm not sure if it supports ESC-ESC (and whether the SDK supports it) but I'm excited to try. If not, I hope Anthropic will add it soon since that's a key feature for fixing mistakes.
I think it's just a TAD annoying that this stupid thing uses API key based cost when it has a perfectly good x20 subscription to work with. I just burned through my entire API budget.
Am I reading this wrong, they added support for Claude Code, which should work with your Anthropic sub. The Claude via API that has always been there is not what they're talking about in this anoucement
Which is exactly why I expected it to use my existing subscription, but apparently their integrated Claude Code decided to use the Claude API key I had set in Zed.
Which I didn’t notice until my whole balance ran out.
I got charged $20 by an old app key because I thought it worked with Claude max like Claude code does. Does it work with subscriptions? What a waste of $20. Buyer beware.
Thank you for the quick fix! Your steps worked perfectly.
In any case, I'd like to add that I'm hoping an ACP adapter for OpenAI Codex is in the works; I've grown pretty fond of GPT-5, and would like to be able to tap into my existing ChatGPT Plus subscription; I'd rather not use API pricing at the moment. I prefer using Claude Code vs directly hitting the Anthropic API for the same reason.
Heck, an ACP adapter for Cursor CLI (itself based on Gemini CLI, right?) would even be useful; as that would also let me pick GPT-5.
Is it really comparable?? I use JB IDEs heavily and when I tried Zed a few months ago it felt more like Notepad than IntelliJ. Maybe that’s what you’re looking for and I am sure that’s fast, but they seem to have quite different use cases.
After moving to Zed I also missed good Git integration that I had in VSCode with GitLens.
That pushed me to finally try Jujutsu instead of Git, since it has a CLI (and TUI and GUI, if that's your thing) that are perfectly usable by mere mortals. Now I feel as fast as when I had the Git integration, despite using the terminal.
But if I had stuck to Git, trying GitButler or Sublime Merge was the next option on my TODO list.
When you run Claude Code it lets you pick between API key and Claude subscription login. It sounds like it found an API key in your env and is trying to use that. You may have to find a way to trigger a login to get you into your subscription account.
The editor treats edits from Claude Code as a first class citizen. You can easily review, approve, rollback, etc. Claude's changes in a curated experience that is much faster than digging around in diffs or needing to approve each edit as it is proposed.
i open my nvim on a socket and tell calude code cli about it.
my claude.md has a line "look for lsp errors when you are done editing" so it communicates with neovim on the socket and gets whatever it needs from editor.
Yea, having tried claude code a lot over the last couple months reviewing code is the #1 job in my view. Any tool that helps you do that more quickly and easily is essential to guarding from slop slip through. What a world heh.
It's just about polish and tightness of integration or may even be lack of it. Claude Code for VSCode is basically Claude Code running in VSCode terminal with some integrations for open file, selections and diffs.
I just installed it on my EndeavourOS box. I opened it, it asked my which theme I want. I couldn't click, and suddenly it went into unresponsive mode. A minute later I killed it and uninstalled it.
I keep trying this editor every few months ever since it was announced, but I always have similar experiences. I remember once I managed to start actually editing something before the GUI started to disappear.
I know what you mean. I used to like Emacs but then they added syntax highlighting for Rust and I don't use Rust so I'll never touch that editor ever again.
Just disable it. It seems like they've made is as simple as possible to do so while also being realistic about what it takes to make a successful (read: profitable) IDE the year 2025.
I've found that the sort of people who complain about AI or cryptocurrency don't care if it can be disabled. The mere fact that such functionality exists taints the product for them. I can't say I understand the reasons (I like AI functionality), but that's what I've noticed.
I do care that it can be disabled. My problem with such functionality is that it becomes the sole focus of the development team, drifting their attention away from improving core experiences, such as language and plugin support, polishing ergonomics, and pruning papercuts.
AI is such a bad and tainted term and since LLMs became so prominent it has kind of become synonymous with LLMs and generative AI more broadly.
I honestly think this is for the better, (un)supervised learning models and other machine learning models with a reasonable number of parameters (k-means clustering, Markov Chains etc.) are usually not called AI any more (and honestly haven’t been for some time; machine learning has been much more popular for at least 10-15 years in my experience).
Given the state of information technology in 2025 I think your parent has a good reason to believe AI features ruins everything. It is common in well funded (read VC funded) technology to start with an easy toggle to disable, and then slowly make opt-out ever harder to completely accomplish. Disable 3rd party tracking ads on google platforms used to be a simple toggle as well.
You can think that AI ruins everything, or that tracking ads ruin everything, but the reality is that VC investment ruins everything, because it turns you from the customer to the product.
I guess the eventual culprit is capitalism, where profit is the ultimate goal for everything, so there will never be a single product that is not enshittified in this way.
The best part? If you don't like it, there's nothing you can do! It's the whole culture.
It was always going to be infested with something or other, you don't raise $42M for just a text editor. Could be worse, a few years earlier it probably would have incorporated blockchains somehow.
Seems like a reasonable trade-off to me. I'm happy for them to have a sustainable business model and people seem quite willing to pay monthly for AI. As long as they keep the free version and the ability to disable AI features then I think everyone wins.
The thing is, they will have to switch to maximizing monetization (or die trying). Those investors are ultimately in control, and while they are happy to gain market share for now, that's what they will demand in the future.
They will keep a free version for as long as it's working for them, but you will be monetized, one way or another, sooner or later, and you might not enjoy it.
We brought this upon ourselves. As much as we reviled forking over four
hundred 1998-dollars to use Microsoft Word, shrink-wrapped closed-source
was more honest way to make a living than the current surveillance
schemes.
Many of which were found to have been compromised with malware and have after having been installed millions of times. Extensions are an attack surface emdash I don’t see why it’s better to have more than anyone could possibly ever audit.
Recently I set up a virtual machine running GNU/Linux on Windows, so that I can continue to use Emacs and all my usual tools for developing software, while I am waiting for a friend to make a move in a turn based game. I decided to give Doom Emacs a try. Well, I like the keybindings so far. However, it got issues. When I use neotree, it gets confused with windows (the Emacs term "window", not desktop windows, or the OS). Also it has already crashed twice. Once I even lost some code, which I had to write again. Unacceptable. Why was there not even an Emacs backup file for the file I was editing? Anyway, today I thought: "Why not try one of these other editors in that VM and see, if I like any?"
Yesterday I looked again at LunarVim's website. While LunarVim seems to look pretty, it has a lot of dependencies, including pip, npm, and more. Seems like it is installing stuff from everywhere. Not so confidence inspiring, especially pip and npm installs.
And just now I see this Zed blog post linked on HN! But, unfortunately the website is not inspiring much confidence either. Can anyone explain to me, why I cannot see any _text_ on all of zed.dev, without running JS? I mean, I probably know the answer, or some possible answers, but man, that's already such a turnoff, I already doubt the editor is any good now. Would be good, if they could fix their website, and make simple text, simple text again, accessible and all that. Please get some craftsmanship into this website.
EDIT: 'pparently I said something some people don't want to hear, lol.
I recently un-borked my emacs config and re-downloaded elisp into my brain so I'd be happy to help walking you through the emacs stuff. I haven't used emacs on Windows natively in a long time but I did it for years and found it worked quite well so you may want to try that again.
FWIW emacs these days has native LSP support (eglot) and native tree-sitter supported, but you'll need to grab tree-sitter libraries and LSP servers. For MacOS I found just using brew to install most of these works great, and I wonder if Windows can't work the same way. If you're in a VM you should just be able to have your package manager do the work.
LLM support in emacs is still a bit primitive but there are packages like emacs claude-code that are changing things. Personally I wrote an elisp function which grabs the filename of the emacs window relative to the project root and copies it so that I can just paste it into claude code and have it ask questions or do things.
```
(defun copy-buffer-file-name-from-project-root ()
"Copy the relative path of the buffer in this project to the kill ring"
(interactive)
(kill-new (file-relative-name (buffer-file-name (current-buffer)) (project-root (project-current)))))
```
if you're curious but depending on how you have your clipboards setup with the kill ring, you may need to modify this.
---
As far as fighting the JS fight on the Zed website, well, I think this thread isn't one of those upvote-anti-JS-rant threads that spring up on this site all the time so shrug.
I'm extremely interested in pushing along these fronts even in a performative way, because I don't want to get bogged down in "switch away from Emacs" conversations with coworkers. I've done a lot of modernizing on my Emacs setup this year but I would love a current take on "getting close to cursor" that gets me beyond what I'd had set up with copilot and lsp.
Having tried a bit of Cursor and some Zed I still find Claude Code a lot better than the rest (though maybe now the Claude Code Zed Beta will change things.) That means what I'm mostly doing is keeping Claude Code up in the terminal and having it do things. Claude Code has an option to view diffs in your editor which you can configure and works fine with emacs and its various diff modes (and looks great too.)
I usually always make sure everything in my branch is committed before letting Claude Code loose on my code so I can view the changes normally as a magit diff and then choose whether I want to edit any of its changes (90% of the time) or commit as is (10% of the time.) I can also restore files selectively this way and have all of my git tools available if needed.
If you want deep Claude Code integration Cursor style, then check out https://github.com/manzaltu/claude-code-ide.el . The latest releases of emacs support using `vc` blocks to specify packages so you can grab the elisp package straight from the repo and get it working within your emacs.
If you want a chat style interface, GPTel exists but requires some config (not much but not zero either) before it becomes usable as a general chat tool like Claude Desktop or ChatGPT. I'm working on an elisp package to recreate a chat interface atop GPTel and decrease the config burden.
I mean, I am using standard Emacs daily for some 8y or so. It is just in that VM, that tried Doom Emacs, which crashed twice. Normal Emacs doesn't do that to me. And since I have the VM, I also don't need Emacs on Windows. The VM runs just fine.
That VM runs a Fedora OS and has vanilla Doom Emacs installed, with a few packages activated in the doom config. So it is about as vanilla doom Emacs as it gets.
The main reason I suggest running it natively is the big speed boost. Elisp supports native compilation now and native compiled elisp running natively on your platform is quite fast.
Lucky you because for me, for some reason, their website is randomly down when I click to change page: Web server (host) is returning an unknown error Error code 520.
I love Zed but this has all the hallmarks of something being totally rushed out the door.
It works off the Claude Code SDK, which mean it doesn't support many of the built in slash commands - it doesn't support /compact, which is 100% necessary because when you use this implementation enough, you'll eventually get a "Prompt too long" error message with no ability to do anything about it. Since you can't see how far you are in the context window, it's a deal breaker, since you have to start a fresh chat and might run out of room before you can ask it to create a summary prompt for continuing.
There is no way to switch models that I can tell - I think it just picks up on your default model - and there is no way to switch to Plan mode, which has become absolutely crucial to my workflow.
I didn't see Zed picking up on problems reported in the IDE, it was defaulting to running 'tsc -b' in my directories.
At this point it's better to run a terminal inside Zed and work from there. The official response in the Zed Discord has been "talk to your local Anthropic rep" to get them to support Zed's Agent Client Protocol (ACP).
The Agent Model came out very recently, I’ve been following the GitHub issue over the past days and you can see it was rushed out. But I don’t see anything wrong with that, many AI topics are being rushed out and adding slash commands and other small things are very small things to add once the foundation is there.
Tbf I never use /compact but clear instead, and load in the relevant context anew. I just haven’t seen compacted context to be very useful, so far.
The model is usually so confused after a /compact I also prefer a /clear.
I set up my directives to maintain a work log for all work that I do. I instruct Claude Code to maintain a full log of the conversation, all commands executed including results, all failures as well as successes, all learnings and discoveries, as well as a plan/task list including details of what's next. When context is getting full, I do a /clear and start the new session by re-reading the work log and it is able to jump right back into action without confusion.
Work logs are great because the context becomes portable - you can share it between different tools or engineers and can persist the context for reuse later if needed.
The trick is to parametrize the /compact. Something like "/compact focus on the XZY, the next steps will be FOOBAR, and keep a high level summary of BARFOO"
That makes the compaction summary a lot more focused and useful.
edit: But a work log/PRD is essential regardless!
I’ve been using PRD specs at kick things off, but curious about how to a “work log”. Are there examples of how to do this with CC?
"Implement phase 1 of the PRD, when done update the PRD and move on to phase 2."
yep, exactly, using it like this myself
I think both /compact and /clear are valuable / have their own use cases.
my small mental mode: - really quick fix / need to go over board with context -> just /compact + continue pushing - next phase -> ask for handover document or update worklog, and then send fresh one to new phase.
Thank you for this. I didn't know this was an option.
I notice when I'm getting close and I tell it how to document current state into an .md file. Then I hit /clear and @ the new file.
This is probably very similar to /compact except I have a lot of control over the resulting context and can edit it and /clear again and retry if I run into an issue.
Seems like those issues are largely limited by SDK so urging Anthropic to adopt is the only realistic move
Yeah I was initially excited here, but it feels more like a demonstration of what's possible rather than a working tool.
I found the interface very nice but quickly ran up against limitations on prompt length (it wasn't that long) for example. I am used to being able to give detailed instructions, or even paste in errors/tracebacks.
I'll check back in in a few months.
I love Zed and I'm glad you now have native support for Claude. I previously ran it using the instructions in this post: https://benswift.me/blog/2025/07/23/running-claude-code-with...
One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
I was somewhat surprised to find that Zed still doesn't have a way to add your own local autocomplete AI using something like Ollama. Something like Qwen 2.5 coder at a tiny 1.5b parameters will work just fine for the stuff that I want. It runs fast and works when I'm between internet connections too.
I'd also like to see a company like Zed allow me to buy a license of their autocomplete AI model to run locally rather than renting and running it on their servers.
I'd also pay for something in the 10-15b parameter range that used more limited training data focused almost entirely on programming documentation and books along with professional business writing. Something with the coding knowledge of Qwen Coder combined with the professionalism and predictability of IBM Granite 3. I'd pay quite a lot for such an agent (especially if it got updates every couple of months that worked in new documentation, bugfixes, github threads, etc to keep the answers up-to-date).
You don't have to buy a license; the autocomplete model is open source https://huggingface.co/zed-industries/zeta
It is indeed a fine tuned Qwen2.5-Coder-7B
> I'd also pay for something in the 10-15b parameter range that used more limited training data focused almost entirely on programming documentation and books along with professional business writing.
Unfortunately, pretraining on a lot of data (~everything they can get their hands on) is needed to give current LLMs their "intelligence" (for whatever definition of intelligence). Using less training data doesn't work as well for now. There definitely not enough programming and business writing to train a good model only on that.
If the LLM isn’t getting its data about coding projects from those projects and their surrounding documentation and tutorials, what is it going to train with?
Maybe it also needs some amount of other training data for basic speech patterns, but I’d again show IBM Granite as an example that professional and to-the-point LLMs are possible.
There's an active PR providing inline edit completions via Ollama: https://github.com/zed-industries/zed/pull/33616
You can use a local model! It's in Settings in a Thread and you can select Ollama.
But that doesn't work for inline edit predictions, right?
Ditto, that was one of the dealbreakers for me using Zed, the Copilot integration is miles behind Cursor's
> Ollama
You mean an locally run OpenAI API compatible server?
thats why i created myself nanocoder 0.5b FT for autocomplete in couple of days going to release a v2 version much better
https://huggingface.co/srisree/nano_coder
I'll third this. AI autocomplete is THE most efficient and helpful feature of Cursor, not the agents.
I use Cursor solely for the agent mode and do all my editing in an proper IDE, meaning Jetbrains products.
I genuinely don't understand why one would want to AI autocomplete. Deterministic autocomplete is amazing but AI autocomplete completely breaks my flow. Even just the few seconds of lag absolutely drive me nuts and then it often it is close to what I wanted but not exactly what I wanted. Either I am in control or the generative AI but mixing both feels so wrong.
I am happy people find use for the autocomplete but ugh I really don't get how they can stomach it. Maybe it is for people that are not good at typing or something.
Same sentiment for me. I barely use the agent, but love their autocomplete. Though I sometimes hear people say that GH Copilot has largely caught up on this front. Can anyone speak to that? I haven’t compared them recently.
If performance were equal, I’d strongly consider going back to GH Copilot just because I don’t love my main IDE being a fork. I occasionally encounter IDE-level bugs in Cursor that are unrelated to the AI features. Perhaps they’re in the upstream as well, but I always wonder if a. there will be a delay in merging fixes or b. whether the fork is introducing new bugs. Just an inherent tradeoff I guess of forking a complex codebase.
They haven’t. They had time to catch up, but they didn’t. They recently switched their auto complete model from 4o-mini to 4.1-mini. It’s not smarter at predicting what you are trying to do. Nothing magical like last year experience on Cursor (I haven’t tested lately, so it might be even better now).
I heard Windsurf is quite good and the closest to Cursor magic, available on Windsurf free plan (unlimited autocomplete). I should give that a try.
They plan to allow defining your own endpoint for auto-complete soon and when they do switching to a better model like Sonnet or a fine tune should beat Cursor
I don't know, I think it's a tie. I can have the agent do some busy work or refactoring while I'm writing code with the autocomplete. I can tell it how I want a file split up or how I want stuff changed, and tell it that I'll be making other changes and where. It's smart enough to ignore me and my work while it keeps itself busy with another task. Sort of the best of both worlds. Right now I have it replacing DraftJS with another library while I'm working on some feature requests.
I feel like this is the big divide, some people have no use for agents and swear by autocomplete. Others find the autocomplete a little annoying/not that useful and swear by agents.
For me my aha moment came with Claude Code and Sonnet 4. Before that AI coding was more of a novelty than actually useful.
I have recently been using Zed much more than cursor. However, the autocomplete is literally the only thing missing, and when dealing with refactors or code with tons of boilerplate, its just unbeatable. Eagerly awaiting a better autocomplete model and I can finally ditch Cursor.
Out of curiosity, why not just stick to Cursor instead?
For me, the editor is still the most important component of my tooling. The AI features are secondary to my needs/wants when it comes to an editor.
Zed is hitting all the checkboxes when it comes to performance and user experience (yeah, I care about that in my editor).
I'm not a hardcore user of AI, but I do make use of Zed's inline suggestions and occasional use of Opus 4.1 through my Zed subscription.
This is it, in terms of pure text editing zed is the best GUI land editor I've used.
Not quite there with emacs/vim but it's a much more accessible environment and more convenient for typical workloads.
I agree. I used to use vscode, then switched to Zed and used it for over a year (without AI). In February of this year, I started using Cursor to try out the AI features and I realised I really hated vscode now. Once Zed shipped agent mode, I switched back, and haven’t looked back. I very strongly never want to use vscode again.
I'm in the same boat but a neovim/cursor user. I desperately wish there was a package I could use in nvim that matched the multiline, file-aware autocomplete feature of Cursor. Of course I've tried supermaven, copilot etc, but I've only ever gotten those to work as in-line completions. They can do multiline but only from where my cursor is. What I love about Cursor is that I can spam tab and make a quick change across a whole file. Plus its suggestions are far faster and far better than the alternative.
That said, vscode's UX sucks ass to me. I believe it's the best UX for people that want a "good enough and just works" editor, but I'm an emacs/vim (yes both) guy and I don't like taking my hands off the keyboard ever. Vscode just doesn't have a good keyboard only workflow with vim bindings like emacs and nvim do.
What Zed lacks in code generation quality it makes up for in not-being-an-Electron-app
Every single new HN thread should come with an automod post badmouthing Electron to save everyone time.
its a bad anti-pattern that trades developer convenience for performance, UX etc. Its fair to hate on it
With the advent of coding agents, I really hope we see devs move away - back to the traditional approach of using native frameworks/languages as now, you can write for 1 platform and easily task AI to handle other platforms.
This will never happen and it's a bizarre, legacy fantasy, borne of a fixed imaginary ideal of what computing should be. Programming will continue to move in the direction of ease-of-use and every time I see an out-of-topic reference to Electron in this forum I feel insane, like I'm fighting upstream. You will not see this - you will see more Electron apps, because that is the modern way of building cross-platform apps, and if you genuinely don't understand why that is I don't know how to explain it to you. You won't see another version of those because nobody is going to waste their time building cross-platform native apps at a native layer to performatively impress posters on HN. You, and seemingly everybody else on HN, can continue to pretend that devex doesn't matter, but that's the difference I guess between caring about devex and shipping products.
It's not out of topic. We're discussing the Zed editor. Their whole marketing ploy is "we are not electron", "we are rust", "we are native", "we are not slow" alternative to VScode.
This is literally their whole distinguishing feature and people are switching because of it and just it.
It is! If the thing runs like shit, say it runs like shit. Say it's native or not, like every topic title and comment on HN until we weep of boredom. I know it's rust! everything is rust here! Is there any other reason I should care? Are we a forum for discussing interesting technology or are we a forum for discussing alternatives to VSCode? And again, who is switching? People shipping products or HN posters with their dumb metrics?
People who install zed are switching. I don't understand what you're trying to "get" at. You're complaining about people talking about Zed in a topic about Zed.
Zed seems to have been hugely succesful recently and their only real distinguishing feature is "fast from the ground up". It has less features than vscode. Worse AI features than Cursor. but people seem to love it nonetheless.
Turns out there is a market for people fed up with VScode-derivatives.
Cross platform application development is cool but the guys who made Zed are the guys who made Atom are the guys who made Electron, and they pointed out that long term the devex sucks and that Electron simply isn't a good platform for native applications that need any kind of memory control or similar features: https://zed.dev/blog/we-have-to-start-over
> My experience in Atom always felt like bending over backwards to try to achieve something that in principle should have been simple. Lay out some lines and read the position of the cursor at this spot in between these two characters. That seems fundamentally doable and yet it always felt like the tools were not at our disposal. They were very far away from what we wanted to do.
> Nathan: It was a nightmare. I mean, the ironic thing is that we created Electron to create Atom, but I can't imagine a worse application for Electron than a code editor, I don't know. For something simpler, it's probably fine, the memory footprint sucks, but it's fine. But for a code editor you just don't have the level of control I think you need to do these things in a straightforward way at the very least. It's always some... backflip.
Thinking Javascript was a language meant for desktop applications is what is insane - even more so than the convenience of using it, which is comparatively less insane.
Absolutely nothing new has been said about Electron since like 2015, it's boring as hell to downvote and scroll past.
Fucking Amen.
I find Zed has some really frustrating UX choices. I’ll run an operation and it will either fail quietly, or be running in the background for a while with no indication that it is doing so.
and then loses by not having plugin support
It does have extensions, but they are much more limited. In particular they can't define UI elements inside buffers, so you can't replicate something with rich UI like the Git integration in an extension.
Does it really? At the end of the day i need it to do my job. Ideal values don’t help me doing my job. So i choose the editor best suited and the features i need. And that’s not zed at the moment.
There's an analogue here with programming language iteration— Python, Ruby and friends showed what the semantics were that were needed, and then a decade or two later, Go and Rust took those semantics and put them in compiled, performance-oriented languages.
Electron has been a powerful tool for quickly iterating UIs and plugin architectures in VSCode, Brackets, Atom, etc, now the window is open for a modern editor to deliver that experience without the massive memory footprint and UI stalls.
I agree with the main point but I am on battery often and the difference between native vs. one or multiple Electron apps in "doing my job" is easily several hours lost to battery life or interruptions for charging. Not a huge deal, but it's not my ideals that make me frown at charge cycles occurring twice as often.
This is simply not true… that’s the problem. As much as I like Zed, using it for the sake of not being an electron app doesn’t make any sense when Cursor’s edit prediction adds so much value. I’m not starved of resources and can run Cursor just fine – as far as Electron apps go VS Code is great, performant enough. I value productivity. I’ll very happily drop Cursor for Zed the second edit prediction is comparable. I’m eagerly waiting.
Zed includes node.js runtime and 100s of megabytes of javascript. It is essentially Electron.
I'm gonna need you to back that claim up dawg, because the only thing I see the node runtime used for, is for when the user loads a js project.
then it's basically just a proxy for node/npm afaik.
Complete nonsense.
https://zed.dev/blog/videogame https://zed.dev/blog/we-have-to-start-over
~/.local/share/zed/
No one's debating your first sentence, they're debating your second.
I wonder if Augment [1] are working on a Zed plugin.
I've been using Augment for more than a year in Jetbrains IDEs, and been very impressed by it, both the autocomplete and the Cursor-style agent. I've looked at Cursor and couldn't figure out why anyone needed to use a dedicated IDE when Augment exists as a plugin. Colleagues who have used Cursor have switched to Augment and say it's better.
Seems to me like Augment is an AI tool flying under most people's radar; not sure why it's not all over Hacker News.
[1] https://www.augmentcode.com/
I now plain hate Cursor's auto complete, it's too aggressive I cannot write any code anymore, it seems to have hijacked CMD too, not just tab.
This is why I’m not a fan of auto complete in my editor. Much rather pair program with an agent.
Give the agent as much context as possible and let it go, review and correct the implementation, let it go again, finish it off…
The I just find the autocomplete a little annoying in my workflow, especially with the local self-hosted models I need to use at work.
Claude Code on corporate approved AWS Bedrock account.
I like autocomplete when it used to be a bit slower and only act on tab.
Right now it's borderline impossible to write code, the autocompletion results are loaded ultra fast and Cursor maps different buttons to autocompleting functionality.
It's no longer usable for me.
I'm fine getting autocompletes, but I decide when to trigger it, ideally after reading it, like this I can't even type.
I'd also like to second this and probably will in every Zed post. This is the primary reason I'm not ready to switch to Zed just yet.
>One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).
It's not only the autocomplete. I've never had any issue with Cursor while Zed panicked, crashed and behaved inconsistently often (the login indicator would flicker between states while you were logged in and vice versa, clicking some menus would crash it and similar annoyances). Another strange thing I've observed is the reminder in the UI that rating an AI prompt would send your _entire chat history_ to Zed, which might be a major red flag for many people. One could accidentally rate it without being aware of that and then Zed has access to large and potentially sensitive parts of your company's code - I can't imagine any company being happy with that.
>I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed
There are plenty of great VCs out there, going with Sequoia will definitely come with some unpleasant late consequences.
>This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode
There are many "real competitors" to Cursor, like Windsurf, (Neo-)Vim, Helix, Emacs, Jetbrains. It's also worth being aware that not everybody is too excited about letting AI slop be the dominant part of their work. Some people prefer sprinkling a little AI here and there, instead of letting it do pretty much everything.
> I've never had any issue with Cursor
Glad it's working for you but I think you might be the only one!
Glad it was helpful :)
I’ll keep an eye on this ‘proper’ Zed support for sure, although the current setup is working just fine so I might wait for v0.2.
"even pulling up a file via search is more accurate in Cursor"
Huh? it takes it sometimes like 40s to find some file with the fuzzy search for me. In that time im going to the terminal running a "find" command with lots of * before I get some result in cursor
I want to try Zed but the Helix mode seems quite young. Vim mode sounds good, but i just can't move away from Helix mode. (oh and of course, my own modifications to Helix's input config)
My difficulty in finding editors that fit my desired input scheme kinda reminds me of the old pre-LSP days. Where you'd chose an editor based on it's language features. I wonder if we need some sort of common editor interface to allow these sort of text editing primitives to work in new editors, as it seems to be considerable friction.
I agree, I've fantasized about an editor with a truly pluggable editing model which is decoupled from the other parts.
Yi was kind of designed like this, I believe. You could compile in an emacs-like model, a vim-like model, or presumably make your own model.
I've used Helix and Kakoune in addition to Emacs and Vim, but dealing with the limitations/featureset/plugin treadmill gets a little tiring.
I have been following Zed, and it seems that they have rearchitected things to enable adding Helix mode and making the editing model a bit more modular, but it's still fairly new. They are fixing bugs pretty quickly. I will have to try it again.
They have a nice discussion here:
https://github.com/zed-industries/zed/discussions/6447
They reference Ki, which also looks cool, and they out some of Helix's inconsistencies in their comparison: https://ki-editor.github.io/ki-editor/docs/comparisons/
I prefered Kakoune to Helix (it was more consistent). But to your point, being able to swap these things out more easily would let you choose an editor based on features, and not tradeoff between features and an ergonomic editing model.
Ironically you can use Ki inside of VSCode (and I know you can use Vim that way too), but VSCode is so darn bloated and slow...
The truly pluggable editor is emacs. I too spent months trying out neovim, then emacs, then finding helix. Spent a year on helix, then zed because I would rather have something more complete, and brought with me all i could of helix modal editing.
But emacs. Emacs is the one that can truly become anything you like. And with lsp and treesitter being finally in it. I've finally came to my senses and started building my helix in it.
I wish some radical team just says fuck yes, we're gonna make Emacs fast and actually accomplishes it.
It's definitely easier with LLMs now, but still considerably hard.
LLMs don't make it any easier at all.
But the team is out there ; )
Epsilon is fast emacs
It’s exciting that Zed even has a Helix mode. That was a big moment for Helix.
Last time I tried it, though, I immediately ran into parts of the keymap that hadn’t been translated yet. I’m already at my limit of tools in beta mode/built from my own fork, so I switched back to Vim mode – where the team is on record explaining their thorough testing methodology.
As a Helix user of two years, I sometimes wonder if I actually like the Helix keymap (certainly some parts are nicer than Vim’s) or if I simply tolerate it because of how nice it is to get a polished TUI IDE out of the box. Either way, my muscle memory expects Helix mode now, rather than Vim.
Neovim can run in server mode, where other editors send it user input and then Neovim sends back the buffer. This is how I use vim in VSCode — not the Vim extension but the Neovim extension, which uses the real Neovim, which of course reads my Neovim config and plugins and makes them available to VSCode. So it seems like helix “just” needs a server mode, and then you can integrate it into any editor.
Helix seems to have good LSP support from what I can tell? The only language I use at $WORK that doesn't have full support is GraphQL which lacks auto indent.
If you want to try something similar to Helix in emacs, there's meow-mode. While I'm not a helix user myself, it shouldn't be too difficult to get meow to work like helix.
If you are already familiar with Vim bindings is Helix's object then action really worth that much?
I thought the same, but I gave Helix a shot for fun a couple years ago and never looked back. It really does feel better/more ergonomic, but the greatest benefit is that almost everything you need is built in. I spent way too much time fiddling with Vim and NeoVim configs.
For me, definitely. Plus it's quite the muscle memory switch. I switched to Kakoune ages ago, and then eventually Helix because i liked its design a bit more.
Helix itself seems quite young - and first time I’m hearing of it.
It’s about 4 years old, twice as old as Zed!
Same age:
commit b400449a58507cca1fa007197929c2cfd6beabbe
Author: Nathan Sobo <nathan@zed.dev>
Date: Sat Feb 20 10:02:34 2021 -0700
Wow!
I had the exact same problem. I was so stoked to try helix mode and then realized it obviously doesn’t have any of my backspace shortcuts. Duh, but still… back to helix!
Oh what, there’s a Helix mode now?
Been wanting to learn Helix more and using it for small edits but never saw a Helix mode in any editor yet
I like Zed in concept. I like Zed in the architectural and foundational aspects. I want more tools like Zed to exist.
But, I find Zed challenging to adopt due to random nuances. First, settings management is a mixed bag and sometimes I just want a quick way to open the "settings.json" from the settings pane without fussing around. Then I'd like the "settings.json" to stay open (reopen) on a restart of Zed. Then I'd like the ability to use an LLM that doesn't have native tool calling support, which Zed seems to be the only app I've used that doesn't have a workaround. Then I'd like the UI to be a little easier to navigate as a new user, it feels a bit scattered and overwhelming at times.
I haven't used Zed much and I may give it another shot (soon), but it very much feels like a tool built by engineers for engineers... Which is great for power users, but seems not so great for new adopters.
I don't think the shortcomings are a blocker, but they are the reason I haven't adopted Zed. The shortcomings are just enough for me to take a step back and say "maybe I'll try again later".
The nuance situation is rapidly improving. I had several minor issues with Zed ~6 months ago, and most of them have been patched away.
While true, I've noticed there's so many changes between Zed and the plugins that other things break, and it's hard to track down exactly what broke.
For what it's worth, I think Zed now has a default keybind to open settings.json: Ctrl+,
I assume that keybind is also configurable?
protip on macOS cmd+, is the standard keybind for opening any app's settings.
Minus web browsers. I read your comment and literally zoomed haha. Totally blanked out.
They mean holding the Command key when pressing the comma key, which should work.
You can also use the command palette searching for "open settings". And the settings.json editor have LSP support
Good to know, thanks!
I spent a while trying to set it up, as I share your general take on their ethos. Personally, I'm okay with a 'power user'-focused text editor, even! But the relative lack of syntax highlighting options got me to give up. Maybe I'm just spoiled from SublimeText's dope, complex, extensible system for specifying "contexts" in themes, but Zed was just nowhere near enough for me.
The keybinding system is also nuts if you turn on Vim mode, but I think I'd eventually get used to that. But functions need to be a different color than arguments, which need to be a different color than local variables... Just non-negotiable.
I look forward to trying it again sometime soon! The AI features seem rad, this included.
Zed does have a way to run LLMs without tool calling. From the agent pane, in the menu, select “new text thread”. I believe there’s a keyboard shortcut but I’m on my phone right now.
I'll take another look but from what I perceived all attempts to start a thread included tool calling in the payload.
I couldn't seem to get any message through without tool calling instructions in the payload. What you're describing sounds exactly like what I attempted.
I tried something like over 6 different variations of model configs with restarts of Zed in-between. The documentation and what Zed tries to configure are different as well. The fields don't match up with the built in type checking. I tried "openai" with the endpoint configured, "openai_compatible", and even "openrouter" hoping the REST signatures would be match well enough. Each configured with various fields to turn tool calling off and every single request that hit the REST server had tool calling.
You should have a drop-down for selecting a tool profile next to the drop-down for model selection. Select "Minimal" for no tools.
"New text thread" should also have no tools I believe.
https://zed.dev/docs/ai/agent-panel#profiles
Text threads include no tooling. They are plain markdown texts you can freely edit (including llm's responses) so you can fix small stuff yourself without annoying, context-polluting back and forths with the llm, at the potential cost of possible caching optimisations.
I tried it and I think it's still missing a few important features.
- I don't want to constantly auto-accept. The point of auto-accept is that it auto-accepts. Seems like a bug.
- It'd be great if I could go back to a specific message and delete the ones I don't want, similar to the CLI version.
- Where is Plan Mode? Maybe I just couldn't figure out how to get to it.
- I can't easily see Background Tasks.
- How do I change models?
- How do I create new sessions (via /new for instance)? Why is `/clear` not supported?
- I don't want to see the entirety of the edits in the terminal. Can they be collapsed by default? Or maybe show a preview?
Note: if you use SSH-based remote development, this doesn't work.
https://x.com/sridca/status/1963271904384401886
That's unfortunate. I use Zed and I'm moving towards containerising my dev environment (using SSH remote dev to connect Zed to the container) because all this agentic stuff seems like a security nightmare. At the very least I want to restrict the blast radius to my repos dir.
I would give them a week or less to support this. They've been improving the debugger so fast, it will take them no time to support remote claude code connections.
Remote dev isn't very good in Zed, unfortunately. For some reason they chose not to apply the local editor's settings to a remote session by default. Every remote has its own config file. Questionable choice, imo
Any reason for this? Is it something temporary or it will never be supported?
IIRC it doesn’t work in Cursor either, and their own AI sidebar was getting weird issues too. Mostly switched back to VSCode for SSH workflows because of that.
zed crashes completely now for me when using a remote env over ssh since a couple releases ago.
Zed is my favorite editor in a long time, and thats without diving into its AI support.
Really love Zed after working in it full time for a month now and pay their 20$ sub tier to support them even when I rarely use the LLM integration beyond the auto-complete.
At first I was very dismissive of it due to being Apple-first but they've turned it around with really good Linux support and it seems like Windows soon as well!
Also love Zed, but sigh, it's VC funded. We all know how this is going to end. Best VIM mode ever implemented in a (non vim) app. I use it as my 2nd editor (most of the time in Jetbrains products).
I just hope I'm wrong about the medium term impact of the VC funding but rushing AI AI AI out seems to be a sign of that rather than fixing fundamental issues that remain such as the ugly font rendering.
Zed being OS is 100% what's keeping me from moving away. If anything happens you just fork it and accept it as-is
VS Code is also open source but a lot of Microsoft's extensions for it are closed source. I hope Zed won't go the same path.
Agreed, though being OS is no panacea as we have seen from countless other projects, but it does mitigate some concern of investing in an editor and its ecosystem and getting rugpulled.
You basically have to choose from
- Zed: VC funded open source
- Sublime Text: indie closed source
None is ideal, but I guess we all know why.
This interests me but they don't address practical Claude Code Opus 4.1 use at scale.
I have a $200/month Anthropic Max subscription that I use for help in exploring and coding my math research. As of now no AI model can compete with Opus 4.1 for helping me with my most challenging tasks. I try every one I can. Gemini 2.5 Pro is great for code review and a second opinion, but drives off the road when it takes the wheel.
I tried a $100/monthly plan and spent $20 in an hour the first time I went over; an API key is not a practical way to use Opus 4.1.
There are plenty of concerns using Clause Code in a terminal, that Zed could address. Mainly, I can't "see over AI's shoulder" so I need to also test. The most careful extension I coded was terminal sessions we could share as equal participants. Nevertheless, as a rule I'd attribute my relative success to just living with shortcomings, as if a "partner that snores". AI loses track of the current directory all the time, or forgets my variable naming and comment conventions? Just keep going, fix it later.
How can I get equivalent value to my Max plan, using Claude Code Opus 4.1 with Zed?
I use zed and claude code side by side right now. I haven't tried out the newly released assisted agent mode with Zed.
Yes Opus has been good with instruction following and same with Gemini for 2nd opinions and brainstorming.
They're not perfect but definitely I see plenty of value in both tools as far as they are reliable services.
I don't like the cloud based functioning of the models as the experience is extremely flaky and not reliable. I've gound OpenAI Codex and the models in codex too be more reliable in responses and consistency of the quality service.
I would still prefer to have a fully locally hosted equivalent of what ever the state of the art coding assisstant models to speed up work.
That will take time though as in with every technological evolution. We will be stuck with time sharing for sometime haha. Until the resource aspect of this technology scales and economizes to become ubiquitous.
Maybe there's a way to use your Max plan? I heard OpenAI works the same way, there's a way to use the codex cli with your chatgpt subscription (I think it gives it a jwt token or something). There are 3rd party tools that can then use the same token to make API requests via the subscription, instead of via API billing. (Which is sort of allowed, since the cli is open source?)
I'm guessing claude code works roughly the same way?
>h Opus 4.1 for helping me with my most challenging tasks
I switched to gemini 2.5 pro, after some prompt tweaking nothing really beats in actual coding tasks imho.
Their landing page via Safari manages to crash my iPhone 11 Pro repeatedly, namely crashing Safari but also another app and the Bluetooth connections - had not seen that before so they are clearly innovative.
Honestly, I’d love to know why that happens. Can you take a look at the logs? On Mac, you can do it through the Console app, and on Linux, through idevicesyslog.
Zed is so great, I do wish they would focus just a little bit more on bringing the UI just a bit more up to parity with VS Code, I would switch full time.
Anyone running this on Linux? I find it works fairly poorly there. To be fair, vscode is also not great for me (especially vim mode) on Linux.
Running on Linux here. Working great for me. If you are referring to font rendering, unfortunately the Rust ecosystem for it is still young, so there are improvements to be made.
I don't notice any major issue yet, except for that freezing on wayland which seems to be fixed already.
Zed was working great for me on linux. It recently broke support for using a remote env over ssh, but locally still works fine.
What's so great about zed ?
It uses a fraction of the memory of VS Code and is much faster to launch.
Do people really need that with modern computers? My computer is 10 years old and I just restarted VS in the last project I was working on. It was about 4-5 seconds before I could edit the text, which doesn't seem long. And I have 17GB available memory. Anyway it doesn't matter because I just don't restart VSCode that much. I do open projects in new windows and those can get slow, but the slow ones are mostly just rust code with rust-analyzer overhead, and when dealing with rust, slow-opening projects are only the beginning.
I don't know, it feels like Zed popularity is just people chasing the latest editor hotness, a time-honored traditional programmer ritual to be sure, but still, just a ritual. And now it seems zed devs have to put AI in front of all other initiatives, probably because of the VC funding they took.
I could see not wanting to use VSCode for other reasons, like MS pivoting back to "be evil", but at least in my little bubble, performance is not one of them.
I agree with you.
I tried Zed several times and I just don't see the point.
The main issues with VScode over something like the Jetbrains IDEs is that language servers are just not as powerful or as integrated to the IDE as the Jetbrains solution can be and Zed does nothing to solve it.
I don't think it being a native app offers much added value.
Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow. Emacs starts up faster than an empty Zed window, unfortunately. It is still way faster than IntelliJ but comparing it to that is a low bar.
VSCodium starts up faster for me than Zed which I compiled yesterday with release mode. Here I am referring to the time spent just on waiting for the window to start up, not the extensions and all that I am using with VSCodium, that takes time. I wonder why this is, that VSCodium shows the window quicker than Zed.
Regardless, I will give Zed a try with Go development. I assume Zed has extensions, too? Are there any extensions for Go? If so, I might replace VSCodium with Zed but only if it has similar features to VSCodium. If not, I will stick to VSCodium as there is no reason for me to change.
Zed has easy to use extensions, but also Go support is built in. (syntax highlighting, gofmt on save, and language server support)
It's builtin? Nice. I will give it a try, then!
I wonder why the startup time is slow though, may have to debug that one.
I'm not a Zed developer, but I'm pretty sure LSP interfaces are pretty much standardized now, in large part to VS Code's efforts, so they're pretty consistent across most editors that support them.
That doesn't mean Zed will have all the other extensions that VS Code has... Recently added the new SQL Server extension(s) and it's been at least interesting, in a way slightly better than using SMMS. It's pretty much burrowing the UI from Azure Data Studio (or whatever it was called). Haven't tried similar for PG/SQLite etc yet.
VScode starts very quickly for an electron app. MS did a great job there.
Memory usage of the IDE doesn't matter much when your language servers can eat 10s of gigs of RAM.
> for an electron app
But the comparison here is broader than electron apps...
It’s built by the team that built atom which was way better than vscode but was mothballed when Microsoft bought GitHub.
They built it from scratch and not on electron bloat so it is a much better foundation. It will take a long time to reach parity with vscode but when it does it will smoke it.
So...nothing.
I think you do not understand the value proposition of Zed.
It is an editor made for people who are used to double-clicking individual files rather than opening a folder in VS Code, so they close and open their editor dozens or even hundreds of times per day.
Let's say VS Code takes 5 seconds to boot.
Some programmers may argue: "yes, I spend 3 hours on a project or just leave it open overnight, so 5 seconds per week is nothing"
But here is not the case, it is for programmers who come from Notepad/Sublime/Notepad++/emacs/vi, and who opens a single file and closes the editor right after.
If you work 2 hours, maybe 4 files per minute, this means 120 * 4 openings = 480 openings.
It means you would have wasted 2400 seconds (40 minutes per day!) waiting for VS Code to open (about 33% of the 2-hour work session spent waiting)
Yes, like with Notepad or Zed, you lose some features like Colors or Syntax checking, but still, time is the most precious thing in life.
For users who come from very advanced but slow text editors like Microsoft Word (used in coding exams: https://stackoverflow.com/questions/76102874/single-and-doub... or programming courses: https://youtu.be/0TVugOJtAiU?t=162 ), this is truly revolutionary and life-changing.
This has to be a joke.
No one ever closes emacs.
You are right. I don't understand.
How can any software developer work when they need to open and close 4 files per minute? I have never met or heard of anyone working like this.
Right lol. It's so ridiculous
Your comment is as insulting as it is indicative of a complete lack of knowledge about the world of editors and software development in general.
If you think "build by atom team" and "not electron" are any kind of serious advantage for any peace of software than your are the one who lacks knowledge about software development.
Made me think about: https://news.ycombinator.com/item?id=43041923 where they mention Atom as well
It would be relevant that they were the team behind Atom if they seemed to understand the lessons of Atom...
Instead of learning from what worked and fixing what didn't, they just threw everything away and wandered off in some totally different direction. They did the reactionary kind of learning instead of the theory-building kind: https://xkcd.com/242/
A complete lack of knowledge? At least GP understood 90% of his peers don't know vscode is built on a browser framework, and wouldn't care.
Did you miss the point about it being built on a fundamentally better tech stack by a team with a track record of better design decisions?
It is new and is talked about a lot on HN and Reddit. And it is not developed by Big Bad Corporation, instead it is developed by Good VC-backed Startup.
In this demographics, hype rarely is connected to technical qualities, they are used more as a post-hoc rationalization.
Snappiness is the primary reason for using Zed.
What do you feel is missing from the UI?
Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992
That figures, their lead platform was the Mac where HiDPI is totally ubiquitous, so their renderer probably has no provisions for subpixel font rendering.
It's frustrating because even on macOS, every other text editor looks better on a 1440p display.
While I do not doubt that there are people who experience this on some monitor/OS combinations, I have used zed on basic 1080p and 1440p 24" monitors with no issue. Sometimes I have general issues with some monitors in macos, which is usually due to some super-resolution/sharpness setting on the monitor itself that I need to adjust, but nothing specific to zed. All I say is that these issues are far from universal with non-hidpi monitors.
You may not notice because macOS fonts look terrible (blurry) on any monitor that is not hidpi. Zed is just par for the course here.
Meanwhile on Linux and Windows, they still implement subpixel rendering so fonts look great on 1440p.
As I said, I do notice when it is blurry, and in such a case it is a problem with anything that is rendered on that monitor not just zed. As I said, this does not happen "on any monitor" that is not hidpi. I use multiple operating systems on my day to day work, so I am not as brainwashed by apple as to not notice when such rendering issues arise.
I know some people have bad experiences with 1440p and macos for some reason, but I haven't had any such experience that I could not fix. So all these are not universal. Some people act as if any monitor below 200dpi will look terrible on macsos. This is definitely not the case.
Other operating systems have three times the horizontal resolution when rendering fonts. It’s simply not possible to fix it on macOS because they removed subpixel rendering. It’s absolutely true that macOS fonts look substantially more blurry than fonts on other operating systems that implement subpixel rendering when you’re using a 1440p monitor.
This discussion goes back twenty years, with Apple going for preserving the original typeface appearance over crispness. It depends what you value the most and is entirely subjective.
There are 2 issues on Apple:
1) How much font hinting to apply. More hinting changes the shape to make glyphs line up better with pixels so that less antialiasing is required. macOS prefers very light hinting to preserve shapes at the cost of blurriness. This is what you are talking about.
2) Subpixel rendering. This effectively triples the horizontal resolution when rendering fonts, and does not affect the shape at all. Fonts look dramatically better on normal dpi displays when using it. macOS removed support for this many years ago. This is what I'm talking about.
While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.
It's not rare at all. It's more common than not for people developing on monitors.
That's wild to me. That's something I don't think I can ever go back to at this point.
Do you use macOS? Fonts look great on Linux with hinting and subpixel rendering at 1440p. I could never use macOS with such a setup.
FHD and below will keep existing on mobile for hardware and power consumption reasons
My guess: their shaders or text rendering don't account for sub-pixel anti-aliasing, which is critical to getting decent text rendering on low pixel density displays.
If they'd used Skia (which is what Electron and Chromium use), they would've got this for free. Instead they tried to reinvent the world and didn't realise how big the world was.
As far as I can figure out, the root issue is even simpler than that. Their hinter is broken. The edges of characters aren't aligned with the pixel grid, so there's lots of fuzzy/blurry looking text.
I love how we just reinvent the wheel again, and again, and again, and again...
MacOS native apps have had great sub-pixel rendering all along, but I guess since we have to develop everything in Electron now it's time to reimplement all the exiting functionality.
- As mentioned, macOS removed subpixel anti aliasing a while ago
- Zed is not an electron app
- In the linked issue you can see that this issue does not exist in Electron.
> MacOS native apps have had great sub-pixel rendering all along
Apple removed subpixel anti-aliasing in Mojave, seven years ago, because it's not necessary on the HiDPI/Retina displays they ship as standard. They still do greyscale anti-aliasing but that's not the same thing as subpixel.
Discussion from the time: https://news.ycombinator.com/item?id=17476873
> because it's not necessary on the HiDPI/Retina displays they ship as standard.
I disagree. Subpixel anti-aliasing triples the available horizontal resolution, and makes text crisper. The algorithms are known and regardless of the density it should always be applied to text and vector graphics elements.
The RGB stripe layout is so useful that OLED manufacturers are moving to it in 2026, away from the long-derided PenTile where magenta/green fringing is seen even on the densest displays.
In fact rendering on macOS is completely broken, and I don't know how people stand by it. At any scaling factor selected that is not a perfect factor of the actual hardware resolution (the 'looks like' value in Settings), the final framebuffer is scaled and interpolated to the display resolution, and everything is noticeably more blurry.
Windows has had some form of hardware-independent rendering since Windows 7, and proper pixel density control arrived in Windows 8.
Subpixel rendering is effective but it's also a massive pain in the ass to maintain, especially if you want to take full advantage of the GPU. Microsoft has kept it around for much longer but even they are steadily moving away, bits and pieces of the Win11 UI render with greyscale AA regardless of system settings because their newer GUI toolkits don't even attempt to support subpixel fonts.
That said, for something like a text editor where fonts are central the entire application and the worst subpixel edge cases like animation are unlikely to come up, it's maybe not unreasonable to ask them to go the extra mile. It's going to be a sticking point on Windows and Linux for a long time if they don't.
At least on Arch it works fine on 13" 1080p, 24" 1440p and 27" 4k displays.
I won't use zed for this very reason.
Top of my head switching between IntelliJ and Zed:
- Git UI is extremely barebones with no support for other VCS
- No merge tool or side-by-side diffs
- Configuration is all JSON
- Would be nice having a full file tree for the search editor instead of just the list; having the functionality split between a tab and the outline panel is quite clunky.
- Ability to move panels (files/git/console/debugger/etc) into standalone windows or other configurations (multiple docks per side, multiple copies of the same panel linked to a specific tab).
Zed is basically a slightly more featured text editor, so it does a good job when I just want to open something quickly and do small edits. So it's really replacing Sublime Text.
But I find myself hopping out to other tools when I'm using Zed which wasn't really common with IntelliJ. So I still want to use a proper IDE for proper development work.
The IntelliJ 3-way mergetool/diff viewer is best in class. I haven't found anything else that touches it.
> I haven't found anything else that touches it.
Have Claude Code resolve merge conflicts, problem solved.
One area I would not trust CC
"vibe merging"
Me either. I thought by now it would be standard UX everywhere, but that is very much not so.
Sublime Merge comes to mind, but I used it briefly before switching to JetBrains products.
Yeah, no, I tried that thinking it was going to be the JetBrains merge as a standalone product and it simply does not have the three-way sauce. Sublime doesn't even offer any way I can view a live base->left or base->right view as I do the merge does it?
> Configuration is all JSON
Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
> Ability to move panels (files/git/console/debugger/etc) into standalone windows
Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
> Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
Really just a GUI for editing, the storage format can still be JSON and synced/backed up however you handle text files.
It just really nice having settings grouped by categories, with dropdowns for possible values, indicators for changes from default values or values overridden by project settings, search/hide/filters, and tooltips for what it does.
Right now the experience with Zed is: open the settings file, open the default settings file for documentation, and basically use search and copy-paste magic value strings/int/float/nulls into the right nested object/key.
> Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
Really the separate window experience (including the file browser/git pane). Really nice having the git panel just open on a window so you can quickly glance at changed files and quickly jump back to them for more editing. Or having search results able to spawn tabs in another pane/window so you don't have to keep switching back to search or rearranging the tab after opening the file from it.
Or even just expanding the workspace across monitors. Right now you can't even move tabs into its own window or across windows.
Yes, a GUI for settings is nice if only for one thing: so there can be a search box that you can use to search over all the settings to find what you need in a pinch. It's a lot friendlier if I can do something like "Open Settings > Ctrl+F > 'Font'" or whatever than having to go find the manual and look it up.
I don't care about the configuration language so much personally (though JSON is of course pretty lame in a lot of ways for that task.)
You get almost the same effect by typing “font” as a config key and going over autocomplete suggestions.
No side-by-side diff is a deal-breaker for me unfortunately.
I use git icdiff (a plugin) in my terminal. I use Zed and VSCode GUI editors, but I don’t care to use their git tools. Command line git is fine.
https://www.jefftk.com/icdiff
This is a great divider between people who want an IDE vs a text editor - Zed explicit is the latter.
People are bringing up a lot of sophisticated stuff. Honestly for me it would just be a more flexible panel system that lets me see eg: File Explorer, Git UI, AI mode, etc, all at the same time.
I can’t really pin down the reason but somehow vscode just feels a bit more „balanced“ to me - the font sizes, little borders, icons and details, it’s more consistent.
Git: IntelliJ is miles ahead. And we’re talking about essential features like three-may merge panel, diffing 2 files, diffing same file between branches, diffing folders, etc
Tests:. Zed is bare bones compared to IntelliJ (rerun failed tests, export list of failures, go to failed lines easily etc
The AI stuff is cool but it won’t get me to switch from PyCharm.
https://github.com/zed-industries/zed/discussions/20086
Merge tool is the big one for me
I feel like the UI is not as smooth as VSCode. There is a slight lag when scrolling.
Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance. Zed is one of the fastest programs i use. I used to laugh when seeing them market fps and such, but yeesh it's fast
> Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance
Here you go: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
> I found Copilot tab completion completion to be VERY slow in Zed, for some reason.
> Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow
> I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code.
> I mean, good AI tab completion feels like a super power. Zed’s is not that good. It’s slow and normally not at all what I want.
> Zed tab is a lot worse in comparison (partly because it’s slow)
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).
> All I'm saying is that contrary to what someone else said about the software being "fast" I tried it and at startup, it was unusably slow.
> Tried using zed on Linux (pop os, Nvidia) several months ago, was terribly slow, ~1s to open right click context window.
> Zed is as close as it gets, I also use it, but it is still slow and cumbersome sometimes.
I'll stop here. There are other 4 pages of comments to pick anecdotes from, in this simple search alone.
The other examples you listed are valid, but A.I tab auto complete is a model & inference issue unrelated to the editor.
It is a feature that they control. Whether it comes from the model, a bad prompt, a bad provider or a bug in their implementation is their responsibility (especially considering you have to pay per-request AI features).
That’s true if we’re evaluating Zed as a product, but the GP is discussing Zed U.I perf specifically.
Idk if 'linux + gpu = problem' is surprising or very relevant either.
> Here you go
That is a list of search results of people complaining that VS Code is slow compared to Zed.
There are tons of complains about zed performance there.
Do you think messages like this are talking about VSCode performance?
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).
Smoothness and frames per second is the core of why they were building a very optimized editor. Not sure if it is just your machine that it is not leveraging the right bits.
For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.
This could be an issue with GPU drivers. I experienced some incompatibility with GPU kernel drivers that allowed Zed to crash the whole window manager during text selection.
Wait what? Isn't a super fast UI one of their main selling points, what led them to write their own rendering in Rust?
...and now they lose to a web app?
There's a reason everyone writes their GUI apps in Electron nowadays. Browser have spent 30 years figuring out fast rendering, it's hard to beat that, even with native code.
I have no idea what they're talking about. Maybe they're used to a smooth scroll animation in VS Code or something? Zed feels snappier/lighter in just about every way to me.
No kidding. It is /so/ fast. It has remote development like VS Code, and most of the features I use, so it's my main thing now. Claude Code was the only thing that made me wince, since I wondered if I was living in the dark ages. VS Code of course has many more extensions, but I don't use that many.
What most of these comments are missing is the attempt at standardization and unification.
There are a lot of comments that people need X feature in order to switch to Y editor. While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.
It appears that our industry is moving towards adoption, sometimes mandatory, of AI coding agents. Regardless of your feelings on the topic, having good tooling to support this effort comes down to: switching costs, compatibility with existing editors, and a strong ecosystem of third party extensions.
While Cursor/Windsurf jumped the gun on bespoke editor integrations with LLMs - the adoption of MCP and other SDKs for coding agents means it's plug and play. The full feature set will be in every editor connected to every agent.
I think Zed wins on having the lowest switching costs for most developers. Paying down generic solutions like Agent Client Protocol (AC) now is a good strategy. It took multiple parties coming together for us to get TLS, OAuth 2.0, and ECMAScript.
I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).
> I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).
This is such a poor analogy. Yes, a good chef can make do with a different knife, but there is a reason why chefs pay for significantly higher quality knives, keep them sharpened, and treat them with diligence and care, than other kitchen tools. A blunt knife can actually be dangerous. Consequently, a lot of chefs buy knives that are effectively hand crafted / forged knives out of this relentless pursuit of quality.
> What most of these comments are missing is the attempt at standardization and unification.
> While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.
I think your general perception is not something I agree with. I want to use software I enjoy using. Programming is a creative exercise for me, and I want to use the tools I enjoy. If a tool is not enjoyable to use, I do not want to use it. Sometimes, productivity does increase enjoyment, but sometimes it doesn't. For example, arguably I would have been more productive in my Java days if I used Eclipse, but because the editor was so bad, I preferred to learn the APIs myself and use Sublime Text instead.
I also don't think I'm sympathetic to the survival of any particular editor. Software comes and goes, and sustainably built business models will prevail. All of the AI-first editors hinge on this being the right iteration of this technology, and we simply do not have a long enough timeframe or context to know if this is truly the best way to write code using AI. MCP/ACP, whatever else might be the best strategy for now, but I think it's too early for anyone to suggest that we've come to the right conclusion forever.
As someone who is in the position to see what the next really disruptive innovation is, you're quite right that there exist much, much better ways to write and collaborate on code. Flying leaps of innovation to Zed's tiny shuffle-steps.
Zed spent their innovation budget on Rust and GPUI, and as a result they have no energy to question the status quo of IDEs as a whole. Git and LSP are antiquated but form the bedrock of their plans for the future.
Essentially at this point they can only do spaghetti enigneering: adding more and more complexity on top of the complexity that already exists. IDEs have been through so many iterations of this process already that all the real wins are in refactoring: moving the whole system (and ecosystem) design sideways, which is he one thing they dare not try to do (though it happens to be my forte).
What tools or tech are you referring to?
BABLR -- a parser framework, and agAST, the DOM structure at the heart of our state layer. Come to our Discord if you want to learn more. We're trying to launch in the next day or two here.
Looks very interesting, thanks for sharing. Will be following for sure!
I'm sorry if this is blunt but is Agent Client Protocol... ...good?
It just looks to me like a bolted-on dongle to the past 50 years of kludges in editor design. It hasn't got 1/20th of the value proposition that a proper shared state layer would offer.
My main issue with claude code is running multiple ones in parallel. I don't want to manually do all the git worktree stuff, I just want claude to handle it for me.
So if Zed automatically handles that (where there's a worktree per thread) I can see the appeal. Apart from that, I'm already using Tower to view the changes so I'm not really sure what the value here is.
I tried installing it, and got an error "can't load supported slash commands" – not sure what that means.
You should try Magnet for this! (www.magnet.run) https://www.loom.com/share/ceabf385871e45b88fcb512b6de6b684
I suspect Zed will aim to tackle this issue via DeltaDB:
https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...
Same, logged an issue: https://github.com/zed-industries/claude-code-acp/issues/18
Ona makes this easy: https://ona.com/
It's great that Zed adding this very useful feature, but isn't this effectively cannibalize their own AI subscription plans? Why pay zed $20 when you already pay for claude code and can use it in the assistant panel? You might still want the edit prediction feature, but then why pay zed $20 when you can pay $10 github copilot and can use it to power zed's edit prediction feature?
It’s also great that they’re willing to risk that, in the name of a potentially better user experience. That’s what gets them to win in the long run, not building another walled garden.
Could be cheaper, maybe?
I have been using zed a fair bit with clause api and the 50 free prompts a month that zed provide on the free plan works out to roughly $8 for an equivalent amount of code using the claude api.
But no idea how it compares to the subscription plan.
I am sure Zed is great and I appreciate the effort put in to create it, but nowadays I just cannot imagine switching from VSCode to something else. In my limited understanding, none of the existing alternatives offer anything (and often misses at least something) truly innovative or anything else that VSCode extension wouldn't solve. On VSCode I have about 15 different profiles setup, each with different settings and dozens of extensions based on either a technology stack or a project - it would be really difficult to find a good reason to throw it all away. The idea of switching between IDEs does not appeal to me either. I do use Neovim a little bit too, but most of that usage time was spent on configuration.
It's really interesting point of view. I'm one of those people who avoid using VSCode at any cost. It's slow, it's bloated, the UI is not great, and it's slowly being locked down by Microsoft.
If Zed would not exist, I would be using helix, neovim, or emacs as I did before.
VSCode is actually not slow. The problem is to make it useful you need to add quite a few extensions, and those can be slow. That itself wouldn't be too bad but VSCode doesn't expose any information about what is causing the slowness. You end up with "VSCode is slow and it could be due to any one of the dozen extensions I have installed", which effectively means that VSCode is slow.
It remains to be seen if Zed can avoid that though.
VSCode (and all Electron based editors) have undeniable input latency. Zed is built by the same team that developed Atom and Electron and one of their stated goals is to make up for the shortcomings of these technologies.
If you don't feel that VSCode is slow, it's because you are used to it.
> VSCode (and all Electron based editors) have undeniable input latency.
Start up time, sure. But VSCode was lauded as the first performant Electron based editor. I just tested VSCode, Zed, and vim and I can't see any difference from when I press a key to when a character shows up on the screen (appears instantly). I'd be curious to see the results of a blind test, and wonder if people's biases against Electron are showing up.
>If you don't feel that VSCode is slow, it's because you are used to it.
I don't think this is a fair claim. When you start doing an apples to apples comparison, that is to say make full use of IDE and auto-completion features it's difficult to see a difference given that the latency and speed of the plugins starts to dominate any millisecond difference in input latency or rendering speed.
No. When a press a character key on my keyboard, it should appear in my editor immediately. All other IDE features like auto-completion happen asynchronously.
> When a press a character key on my keyboard, it should appear in my editor immediately.
Seems to work the same for me in VSCode, CLion, and nvim. I don't doubt that you have issues with it (I've experienced slow editors & laggy input, it sucks) but I don't think it's inherent to VSCode. Doesn't mean it's not a bug, but if I had that issue I'd try with no extensions to verify, then binary search disabling the extensions I want until I find the one causing the lag.
>All other IDE features like auto-completion happen asynchronously
in the technical sense, but you as a developer don't use auto-completion asynchronously. It's not like you autocomplete and continue typing and then come back to the completion. When you complete at point you have wait. Whether that keypress takes 2 or 3 milliseconds isn't going to make a difference when the inter-process communication of your editor and its services is magnitudes slower. It's not like programming is like playing an FPS game. You're not in any meaningful sense limited by your mechanical input speed.
Are you telling me that it was a delay when you type in vscode? If so, either your configuration or computer is doing something wrong
> Are you telling me that it was a delay when you type in vscode? If so, either your configuration or computer is doing something wrong
This is simply not true. There is inherent latency in any rendering pipeline, and VSCode and Atom both have input latency that is significantly higher than other editors like Sublime Text owing to a bloated rendering pipeline. You can read more about this and how easy it is to introduce latency simply by changing basic things like keyboards here: https://danluu.com/input-lag/ or editors specifically: https://pavelfatin.com/typing-with-pleasure/
The thing their computer might be doing wrong is just being a slightly older budget laptop, which is not a particularly rare setup.
Just try to use vscode on a ~500 dollar laptop from 2019 or something
It's super noticeable on a high refresh display. VSC is like playing a video game at 20FPS.
Vanilla settings on a high end gaming PC.
If you press a key in VSCode, it does appear immediately.
The difference in startup speed is measured in seconds, bit milliseconds. And difference in input speed can be dozens of ms, which is also noticeable
vscode is noticeably slow compared to sublime text or zed, even without any extension. You instantly notice it when switching files or typing things that trigger auto-completions.
In the end the feeling is drastically different. It weirdly makes for a more peaceful experience to have such a snappy editor.
vscode wins thanks to all its extensions, where basically every language is supported and most features you can think of are there. But it's kinda like modern react. You know better alternatives exist, like solid or svelte, but the community is so big, it stays the easier choice in the end.
I've never once experienced delayed input typing even with a lot of extensions
Latencies associated with typing and switching files are imperceptible on any laptop I've used with VSCode.
You can actually open the text tools on discord and see what's taking up memory and CPU.
They also have a new feature that's experimental that lets you offload extensions to a separate extension host so they don't block on the main thread for poorly designed or performing extensions.
It's definitely not slow in its default for .
Interestingly I disagree with all your points about VSCode.
It's fast, barebones by default, UI is minimal and it's Open Source enough that competitors forked from it.
I guess YMMV because there is a comment in this post from another user about Zed being sluggish.
I tried VSCode many times in my life and just hated the experience so much. It put me away from GUI editors for years, didn't want to try any of them. So ugly and so sluggish.
Zed was the first one that put me to rethink my position. It is so snappy on my Linux workstation and I don't have any issues with it's GUI. I finally switched from vim et.al.
But I know I have "weird" opinions, I also really dislike Apple products and their software.
My experience is the exact opposite
Vscode has never had any input delay for me
Even not counting the LSP, for a text editor, it eats quite large amount of RAM.
It’s not at all slow when compared to IntelliJ products or similar. It doesn’t compete with editors, it competes with IDEs.
Zed's main selling point over VSCode for me is the lack of a slight delay between when I press a key and when the character appears.
VSCode has always felt ever so slightly sluggish to me, and I find it maddening as I type.
So glad to hear I'm not alone! I continue to use SublimeText for this reason. Yet it doesn't seem to bother others.
I think a lot of people forget how long ago Electron/Atom were released, and the subsequent Cambrian explosion of Electron based apps and editors like VSCode. There's probably a huge amount of developers that haven't used anything else.
Ironically, I used JetBrains products for years before switching to VS Code because the latter felt so much faster. So it definitely depends on what you're used to.
Zed feels significantly faster than VS Code, but it also doesn't feel as polished and "complete" as an IDE, so I'm going to stick to VS Code for now for the same reason I stuck to JetBrains IDEs for so long.
Same here, still using Sublime Text due to its general snappiness, but can't wait for Zed to be released on Windows, it feels like a modern successor to ST that just keeps getting better.
Weird, I tried it recently and found it actually a bit laggier than VSCode. The rendering is much worse quality too.
Are you using Vim mode or something like that?
I begrudgingly gave up vim mode in vscode a few years ago, because that seemed to make it so much more sluggish.
Yeah it hooks into some blocking event that gets called on every keypress. At least that's how it worked last time I tried it many years ago. Very sluggish.
Fortunately standard editing shortcuts like Ctrl-D, Ctrl-left/right, etc. replace 99% of Vim "magic" and are way easier to remember and use.
No offense, but if you think ctrl-shortcuts are easier to use you don’t really get the appeal of vim
Strange.
I just opened the same project in Cursor and Zed and started typing around, and I can't tell any difference. I am usually very sensitive to this stuff; for example, I can detect when my Mac drops below 20% battery because ProMotion is disabled and the screen refresh rate drops to 60Hz.
This is why I cannot switch to neovim despite my attempts. I love the workflow, but the delay is too noticeable for me, and nothing helps. It's not a long delay, but long enough for me to feel like I have to wait for hours compared to Zed.
May be Helix editor will be fast enough? In my opinion it feels considerably faster then vim with addons
vscode started to intermittently freeze my whole desktop on arch linux recently. I rage deleted it. imho, it’s a valid compromise to choose a snappy lightweight editor over vscode with all available extensions.
sadly it reminds me of how visual studio used to be and and how much of a sluggish mess it is today. I don’t think the community can fix it either. it’s an uphill battle when MS is known to lose care as soon as they reach a critical mass of users.
VS Code is sluggish for me as well and crashes. I have minimal expansions, this is just a poor excuse for a lousy editor. Zed is much better, neovim is much better. My only real concern with Zed is what bait-and-switch is awaiting for us when they decide to make money. But it's a fantastic editor, no question about that.
There is always a "better mousetrap", and there are those that continue to use the old one because they "know how it works and it's set up just the way I like it". And there are others that try every new mousetrap that hits the market. (and that's ok, not slighting either one)
I will say that I personally have never really gelled with VSCode no matter how much I try to customize it, it still is just a bit off. For me, it's like it's too much to be a simple editor like SublimeText or NeoVim, but not quite enough to be an IDE like IntelliJ or Visual Studio (full). It does just enough that I expect a bit more of it and it often fails to deliver. Right now I tend to just use 2 editors - one very simple one for viewing/editing text files and one IDE (currently IntelliJ) for coding in a project.
On topic - Zed is actually a really nice editor. It had some rough edges last time I tried it, but it's probably about time to give it another go.
I wanted to like VSCode but it has enough input latency on my machines that it's not that enjoyable when I'm "locked in". Also if I'm running a bunch of services in Docker on MacOS (which means they're running VMs sigh) the overhead of VSCode is just too much and the system starts swapping constantly grinding the whole thing to a halt. I also find configuring it a pain. Every configuration pane feels ad-hoc and not part of a holistic, configurable system. Emacs has lots of crusty bits and an annoying event loop that you have to really work around but is designed a lot more holistically than VSCode.
Zed to me feels like a great batteries-included editor and I still run it as my non-emacs alternate editor. I wish its configuration was a bit more discoverable (especially with configuring linters/formatters), but it's 95% of what I need 95% of the time.
I had to use VSCode for some projects in the past because it was what was available on the clients workstations... I can't imagine having to use that laggy electron abomination all the time. For me Zed is sent from heaven, because my previously preferred editor (geany) hast basically zero developtment nowadays.
I normally care a ton about latency and in the main project I work on I put extreme focus on reducing input latency in text input fields, but...
I've used VS Code for ages. I tried Zed. I don't really feel a difference. It's smoother but VS Code is more than smooth enough for me and has tons of features I rely on that don't exist in dev.
Meanwhile, when I tried Ghostty I noticed a significant improvement in "typefeel" compared to iTerm. So I'm not immune to detecting such a difference.
I will try Zed again though.
>>I don't really feel a difference.
>>It's smoother but...
How big was his project bc I've never had any input away and I've worked on some pretty good size projects.
Are you using an old computer or something?
I mainly used VSCode on locked down corporate laptops. Usually good hardware but running windows and corporate security bloat. But where I was allowed to install alternative editors they were snappy.
Zed succeeds at reducing the switching cost. I used NeoVim for ten years daily and configured it way back in college days.
I thought I would be unable to move to a GUI editor and it turns out that the speed and efficiency of Zed plus the almost one-to-one mapping of Vim features means that I am extremely productive in Zed.
I think the point of ACP being an open protocol is so that other editors (e.g. VSCode, Neovim) can implement it as a receiver and integration with ClaudeCode/GeminiCLI/... would just work.
OTOH I'd ten to prefer as less plugins as possible in VSCode, just because they are inherently dangerous, I'd like Zed plugins that are WASM, so they don't have access to the world.
But I agree that VSCode Typescript support is better than Zed, it works with weird projects setup, while Zed has more troubles. I at work VSCode and Zed/Helix for my projects, generally I use Zed when want to do some AI stuff, otherwise I just use Helix.
It sounds like you haven't tried Jetbrains IDEs. I understand still preferring VsCode in that case, but I think you would be saying "I prefer VsCode" vs "I don't see a reason". A big con with JB is they are very slow. The upside is that they manage multi-file projects, refactoring, and introspection far better than VsCode.
I switched to Neovim a year ago, and while I did spend a significant amount of time on configuring it, I haven't touched my config for months now - and I'm perfectly happy with it. There's things I can improve, but it does what I want.
I’m in the same boat. I spent a lot of nights for a couple weeks getting everything tuned just right, in the beginning. But now, several years later, it really doesn’t take much. I spend maybe 2-3 hours once every few months, and that’s usually just adding a bunch of features that sound nice to make my life better. I’ve easily gone 6+ months without touching neovim config, if not longer, because it’s unnecessary. It only matters if you want to further improve your editor
I am sure some would have said the same about why would anyone switch to using Linux when there was Microsoft Windows.
Especially now that Windows has WSL. You can even open GUI Linux apps just as if they were regular apps.
Yeah, but you still have to deal with all the other Windows shit.
I use zed when I need to quickly edit something, it pops up so fast- everything else feels sluggish.
Glad to see this out so quickly. Like I said[0] on the Gemini announcement post, it feels like Zed is trying to get out of the business of iterating on agent logic and just let other people handle it. Any prompting secret sauce a) is trivial to copy, and b) gets eaten by the next model generation anyway. The capabilities of Claude Code, Codex, OpenCode, etc. seem to me to be converging.
[0]: https://news.ycombinator.com/item?id=45045515
Plausible take. My first time using a coding agent was with Zed’s. As a sceptic, I was blown away. Two or weeks later Claude Code dropped and I haven’t used the Zed agent since. I canceled my subscription because 20 EUR/month for AI features I no longer use felt silly. And with the massive investment from Sequoia, and the real possibility of enshittification, I couldn’t mentally classify it as a monthly ‘donation’ to sponsor ongoing development either.
That last part is just me maybe. But I’m sure they poured a lot of time into their (granted, very nice) agent, only for many users to switch to Claude shortly after release. Letting others build the agent but being the place where the agent get used seems like a smart move
I use the zed agent regularly. What does claude code do better?
Fine. Cool step for Zed to push ACP, and I think this is the right direction for the IDE space.
But tbh if it’s not as frictionless as the Codex IDE extension in a Zed-skinned VSCode, it doesn’t matter.
Tried giving Claude and CC many chances, but the cognitive load of constantly managing a hard context window is DOA.
Codex w/gpt-5 is on par if not better than any of Anthropic’s solutions at this point, and the ubiquity (web, CLI, IDE) + UX consistency of Codex under one account/plan just dominates any marginal value of using a different model at a higher price.
Codex just works. Then it keeps working. Then it keeps working.
Any solution that wants to compete with OAI’s latest hostile takeover attempt has to match then beat on “unlimited/anywhere/frictionless” UX across platforms AND price ($200/mo all in).
I don’t see a good way out of this for most, except through major spend on playing catchup.
Guess that’s why Anthropic just raised again. Cursor is clearly trying to play, but they will always be a markup product until they launch their own SOTA model. Is Gemini still alive?
If they could add support for remote development (meaning the claude code instance runs on the remote server in the same folder that you have already opened as a remote/ssh project in Zed) and add a way to paste images in Zed and have them interpreted by CC on the server, this would really be a killer feature.
As someone who’s running a development agency I need to have tens of dev environments for different client projects running at the same time, and being able to switch between them multiple times every day (often from multiple client computers), so a remote server is the only way to go–I don’t want all of that stuff running on my Macs.
Nowadays I also have tens of CCs running on the dev server, switching between them using tmux, which works great, but the lack of support for pasting images through the terminal/ssh/tmux has been a real bummer. It would be great if Zed found a way to bridge that gap.
As a VS Code + Claude Code user, I'm really excited to see progress here, because the official near-zero-config Claude Code IDE integration is... inflexible, at best.
What if I want to send a subset of my open editor panes to Claude Code? What if I want Claude Code to open diffs for its edited files in a specific area/window, and silently open that file so that I can multitask on other things without it taking focus when it's done thinking? What if I want keyboard shortcuts for specific slash commands, or to trigger a slash command from another task?
Having a robust open-source ecosystem that will let users fork and build customizable UI around coding agent experiences will make them even better, and the space will move even more quickly because the ecosystem won't split between different preferences for agent/model choice. It's an incredible time to be coding.
I just installed it and it seems changing mode is unsupported? I can't figure out how to switch to plan mode.
I think the article mentions this not yet being supported by the SDK, and therefore by the editor.
Ah, if it is using the SDK, that is a big limitation. The SDK is nice, but it is meant to provide support for backend use of Claude Code, not integrating an interactive session.
This might come off as a naive question so pardon me in advance for my ignorance. I got Claude Max just last week and I have been using it in the MacOS Terminal app. I also used it in Zed and VS Code terminals and faced no issues. So what is the advantage of using it natively like this?
The post has a video included. More integrated interface seems useful.
You get a diff view of the edits CC is making to your project and there's a mode where you editor's focus follows where CC is editing in your project.
BTW, you get this in VS Code, too. https://docs.anthropic.com/en/docs/claude-code/ide-integrati...
Thanks. Diff view sounds useful
If you're going to live in the terminal, please do yourself a favor and replace Terminal.app with iTerm2, and replace bash with zsh.
Kitty is much better than iTerm2 and while zsh is fantastic, fish is much easier to get started with and also very good.
> and replace bash with zsh
I highly recommend trying fish, I wish I’ve switched earlier
+1 to fish, just efficient out of the box
iTerm2 is what we were using last month, now it's all about Kitty and Ghostty!
It's interesting that VSCode has its own Claude code extension which works well and does most of this.
Zed has a lot of these micro-battles ahead where it has to spend money building solutions that VSCode's community shipped without their core team putting in any effort at all.
Actually, Anthropic built that integration themselves.
Does it? Or do you mean the integration when you run Claude Code from the terminal opened in VSCode? (which is already pretty good)
It does, there's an extension you can install which is even a bit better.
Zed has really good vim bindings + mix of native shortcuts making a powerful workflow. The window management keyboard shortcuts are great and is the main reason I switched from some vscode use. Its kind of what I wanted neovim + tmux to be with less work and setup.
Zed doesn’t have file delete undo and I found the AI autocomplete to be so bad I had to turn it off. I still use vscode for work. Zed is kind of in a purgatory state where its lacking in way to be a main for many folks but its close. Just the AI focus is sadly the best way for it to keep investments going, but are really not the top things I think Zed needs.
I wish it natively supported vimrc, I dislike having to rewrite all my bindings in zed format.
Recent and related:
Agent Client Protocol (ACP) - https://news.ycombinator.com/item?id=45074147 - Aug 2025 (93 comments)
Naive question: is using Claude Code from the command line or in these tools like VSC or Zed different from using it in the native app on a desktop? Is that because it has access to your codebase?
After having troubles with Claude desktop not properly updating canvas document, I found that apparently Claude Code is same as desktop one plus you can use it not just for code but documents in VS Code.
In Elixir/Rails (and newly React) world you can connect Clade Desktop to Tidewave, which gives you pretty close integration with codebase and CLI tools. That makes the experience somewhat similar to running Claude Code in editor's terminal, or now directly connected in Zed.
I think basically all these tools are trying to integrate all the stuff together and find the best way to do that, so that you don't need to be copy-pasting stuff around, jumping between tools, etc.
Not tried with Zed yet, but in VS Code it's mostly the same except you can view the diffs in the editor, and can give context from the open file. I think it can also see errors from the editor.
Not just your codebase, but also a wide range of *nix tooling. Night and day to working on the CLI vs an IDE.
Maybe I'm missing something but Zed is asking me to either login via claude /login or use the Anthropic API key.
How do I configure it with Base API URL?
I wish the release notes of Zed would contain less AI.*, and more focus on getting the core editor capabilities completed. I'm a fan though, don't get me wrong.
They've been chasing nothing but AI crap for months. Maybe a year. They've stopped improving the core editor completely.
I'm getting ready to just switch back to Sublime Text
Immediately crashed for me on Arch Linux. Possibly related to whatever is causing this crash: https://github.com/zed-industries/zed/issues/37247
I've been seeing a lot of crashes of late
I know it is not popular around here, but until Zed gets a windows version:
Zed's dead baby, Zed's dead
There is a Windows version if you're willing to use unofficial builds. I've been using it successfully for a few weeks. There's a few more rough corners than in the official Mac/Linux version, but it's usable.
Thanks. I might once I'll be in a mood to get frustrated by rough corners :-)
Really excited for this. I'm not sure if it supports ESC-ESC (and whether the SDK supports it) but I'm excited to try. If not, I hope Anthropic will add it soon since that's a key feature for fixing mistakes.
I think it's just a TAD annoying that this stupid thing uses API key based cost when it has a perfectly good x20 subscription to work with. I just burned through my entire API budget.
Am I reading this wrong, they added support for Claude Code, which should work with your Anthropic sub. The Claude via API that has always been there is not what they're talking about in this anoucement
Which is exactly why I expected it to use my existing subscription, but apparently their integrated Claude Code decided to use the Claude API key I had set in Zed.
Which I didn’t notice until my whole balance ran out.
I got charged $20 by an old app key because I thought it worked with Claude max like Claude code does. Does it work with subscriptions? What a waste of $20. Buyer beware.
I would've probably switched from JetBrains to Zed already. But Zed has no vertical tabs support.
I can't believe people are ok with horizontally layed out tabs.
Not sure if anyone from Zed is here. I tried this out and got the following error:
Internal error: { "details": "can't load supported slash commands" }
We just pushed a fix! Here's how to get it:
- Start a new Claude Code Thread, which will kick off the background download of the new Claude Code ACP adapter.
- Wait a few seconds, then start another Claude Code Thread. The new thread will use the updated one.
We're working on a nicer UX for getting updated versions, which we'll definitely ship before Claude Code support leaves beta!
Thank you for the quick fix! Your steps worked perfectly.
In any case, I'd like to add that I'm hoping an ACP adapter for OpenAI Codex is in the works; I've grown pretty fond of GPT-5, and would like to be able to tap into my existing ChatGPT Plus subscription; I'd rather not use API pricing at the moment. I prefer using Claude Code vs directly hitting the Anthropic API for the same reason.
Heck, an ACP adapter for Cursor CLI (itself based on Gemini CLI, right?) would even be useful; as that would also let me pick GPT-5.
Thanks! It successfully installed this time, but now I have a new error:
Internal error: { "details": "Failed to intialize Claude Code.\n\nThis may be caused by incorrect MCP server configuration, try disabling them." }
I logged in via Claude CLI using my subscription.
I got this same error. I restarted Zed, and it fixed itself.
Thanks. I tried that. Didn't work.
I got this error too.
Tried restarting zed and restarting my computer, but neither resolved it.
Same!
The only reason i didnt move to zed from jetbrains yet is the lack of a more mature Git UI. Other than that, great editor, very fast.
Is it really comparable?? I use JB IDEs heavily and when I tried Zed a few months ago it felt more like Notepad than IntelliJ. Maybe that’s what you’re looking for and I am sure that’s fast, but they seem to have quite different use cases.
After moving to Zed I also missed good Git integration that I had in VSCode with GitLens.
That pushed me to finally try Jujutsu instead of Git, since it has a CLI (and TUI and GUI, if that's your thing) that are perfectly usable by mere mortals. Now I feel as fast as when I had the Git integration, despite using the terminal.
But if I had stuck to Git, trying GitButler or Sublime Merge was the next option on my TODO list.
How exactly does this work? I have Zed, I have Claude Code, I can't get the two working together.
Funny, when I read
> Escape the Terminal
it does not sound like a good thing to me: a) the terminal is fine; b) AI should not escape anything.
Does this use the API or can it use the Claude subscription?
That wasn't stated or perhaps I missed it.
I've been using with a subscription, both API and subs work.
I tried using Zed with TypeScript and after 5 mins I uninstalled the app.
Does anyone have python library for ACP? Looking to integrate my agent with this.
No support for multiple agents at the same time is a non starter
> Credit balance is too low
I have a subscription to Claude. What gives?
When you run Claude Code it lets you pick between API key and Claude subscription login. It sounds like it found an API key in your env and is trying to use that. You may have to find a way to trigger a login to get you into your subscription account.
Yep, that was it. I had an Anthropic API Key set in Zed. Resetting that (after typing /login in the agent window) did the trick!
In the terminal based Claude Code, use /logout and /login to switch billing iirc.
I wish someone integrate qwen-coder as well
I actually works already, just add new agent definition:
--- "Local QWEN": { "command": "/usr/local/bin/qwen", "args": [ "--experimental-acp" ], "env": {} }, ---
Zed "just works" with ollama, so if you install a qwen modal locally you're set.
Is that much different from just using the Zed agent with Qwen via API?
Qwen-Coder is free.
agreed. waiting for qwen here as well.
qwen keep rebase gemeni so I guess just wait?
the integration is nice, but has some rough edges, I ran into situations that things becomes hard to stop
Still no Windows support for Zed, meh.
It will come! Linux support is only recently getting good. They'll get there.
Bnbn
what i am missing by using claude cli with nvim. i don't understand why editor integration needed.
The editor treats edits from Claude Code as a first class citizen. You can easily review, approve, rollback, etc. Claude's changes in a curated experience that is much faster than digging around in diffs or needing to approve each edit as it is proposed.
https://zed.dev/agentic
i open my nvim on a socket and tell calude code cli about it. my claude.md has a line "look for lsp errors when you are done editing" so it communicates with neovim on the socket and gets whatever it needs from editor.
Yea, having tried claude code a lot over the last couple months reviewing code is the #1 job in my view. Any tool that helps you do that more quickly and easily is essential to guarding from slop slip through. What a world heh.
It's just about polish and tightness of integration or may even be lack of it. Claude Code for VSCode is basically Claude Code running in VSCode terminal with some integrations for open file, selections and diffs.
Please keep the slop away from the editor.
zed extension is too bad to be used as a full-fledged extensible editor, as many features and interfaces are missing.
I just installed it on my EndeavourOS box. I opened it, it asked my which theme I want. I couldn't click, and suddenly it went into unresponsive mode. A minute later I killed it and uninstalled it.
I keep trying this editor every few months ever since it was announced, but I always have similar experiences. I remember once I managed to start actually editing something before the GUI started to disappear.
But hey, it has AI.
This is why I try to avoid building/supporting desktop Linux gui apps
Zed used to be a good editor but it is increasingly LLM infested.
I know what you mean. I used to like Emacs but then they added syntax highlighting for Rust and I don't use Rust so I'll never touch that editor ever again.
The deal breaker for me was when they introduced support for the "delete" key. A real developer should get it right the first time.
IMHO, the delete key can still be useful for other developers "contributions".
git revert works better ;)
Can you believe they had the gall to even run code that allowed those vim heathens to feel comfortable in emacs? The horror /s
Just disable it. It seems like they've made is as simple as possible to do so while also being realistic about what it takes to make a successful (read: profitable) IDE the year 2025.
I've found that the sort of people who complain about AI or cryptocurrency don't care if it can be disabled. The mere fact that such functionality exists taints the product for them. I can't say I understand the reasons (I like AI functionality), but that's what I've noticed.
I do care that it can be disabled. My problem with such functionality is that it becomes the sole focus of the development team, drifting their attention away from improving core experiences, such as language and plugin support, polishing ergonomics, and pruning papercuts.
The focus of the team is gone. Their target now is not to make a great product, but to make an engaging product that makes money however they can.
The AI is a symptom of the problem. If it weren't AI, it would be something else.
make an engaging product that makes money however they can.
Is that not what your employer does?
It is, because they're VC-funded.
Yes. I don't want to give support or market share to a company that is using AI as it is an unethical technology.
Do you also refuse to use search engines, cars, phones, computers, etc? Or by "AI" do you specifically mean LLMs?
AI is such a bad and tainted term and since LLMs became so prominent it has kind of become synonymous with LLMs and generative AI more broadly.
I honestly think this is for the better, (un)supervised learning models and other machine learning models with a reasonable number of parameters (k-means clustering, Markov Chains etc.) are usually not called AI any more (and honestly haven’t been for some time; machine learning has been much more popular for at least 10-15 years in my experience).
Given the state of information technology in 2025 I think your parent has a good reason to believe AI features ruins everything. It is common in well funded (read VC funded) technology to start with an easy toggle to disable, and then slowly make opt-out ever harder to completely accomplish. Disable 3rd party tracking ads on google platforms used to be a simple toggle as well.
You can think that AI ruins everything, or that tracking ads ruin everything, but the reality is that VC investment ruins everything, because it turns you from the customer to the product.
I guess the eventual culprit is capitalism, where profit is the ultimate goal for everything, so there will never be a single product that is not enshittified in this way.
The best part? If you don't like it, there's nothing you can do! It's the whole culture.
It was always going to be infested with something or other, you don't raise $42M for just a text editor. Could be worse, a few years earlier it probably would have incorporated blockchains somehow.
Seems like a reasonable trade-off to me. I'm happy for them to have a sustainable business model and people seem quite willing to pay monthly for AI. As long as they keep the free version and the ability to disable AI features then I think everyone wins.
> As long as they keep...
The thing is, they will have to switch to maximizing monetization (or die trying). Those investors are ultimately in control, and while they are happy to gain market share for now, that's what they will demand in the future.
They will keep a free version for as long as it's working for them, but you will be monetized, one way or another, sooner or later, and you might not enjoy it.
We brought this upon ourselves. As much as we reviled forking over four hundred 1998-dollars to use Microsoft Word, shrink-wrapped closed-source was more honest way to make a living than the current surveillance schemes.
Agreed, but Zed is open source so I think that does offer some long term protection to users who like the editor and don't want AI.
How does the existence of LLM features impact the quality of the rest of the editor? It's a single toggle to disable everything [1].
[1] https://zed.dev/blog/disable-ai-features
The inclusion of an unethical tech is a deal breaker.
One line fix for you…
https://zed.dev/blog/disable-ai-features
Does that button cause them to cease using LLM technology? My objection is on ethical grounds.
Zed lacks an ecosystem for plugins, which is a huge drawback for me. The native debugging UX is cool, but I can get this w/ my VSCode plugins.
This seems obviously untrue. https://zed.dev/extensions
VSCode has ~60k extensions last I checked
VSCode has 60k+ extensions vs Zed's 744. I'm pretty sure there's a clear winner here.
Many of which were found to have been compromised with malware and have after having been installed millions of times. Extensions are an attack surface emdash I don’t see why it’s better to have more than anyone could possibly ever audit.
extentions in Zed are just languages support and themes.
I tried so many times to switch but I’ve reached a conclusion that Zed sucks. It doesn’t even properly support Python out of the box. UI is crap.
Recently I set up a virtual machine running GNU/Linux on Windows, so that I can continue to use Emacs and all my usual tools for developing software, while I am waiting for a friend to make a move in a turn based game. I decided to give Doom Emacs a try. Well, I like the keybindings so far. However, it got issues. When I use neotree, it gets confused with windows (the Emacs term "window", not desktop windows, or the OS). Also it has already crashed twice. Once I even lost some code, which I had to write again. Unacceptable. Why was there not even an Emacs backup file for the file I was editing? Anyway, today I thought: "Why not try one of these other editors in that VM and see, if I like any?"
Yesterday I looked again at LunarVim's website. While LunarVim seems to look pretty, it has a lot of dependencies, including pip, npm, and more. Seems like it is installing stuff from everywhere. Not so confidence inspiring, especially pip and npm installs.
And just now I see this Zed blog post linked on HN! But, unfortunately the website is not inspiring much confidence either. Can anyone explain to me, why I cannot see any _text_ on all of zed.dev, without running JS? I mean, I probably know the answer, or some possible answers, but man, that's already such a turnoff, I already doubt the editor is any good now. Would be good, if they could fix their website, and make simple text, simple text again, accessible and all that. Please get some craftsmanship into this website.
EDIT: 'pparently I said something some people don't want to hear, lol.
I recently un-borked my emacs config and re-downloaded elisp into my brain so I'd be happy to help walking you through the emacs stuff. I haven't used emacs on Windows natively in a long time but I did it for years and found it worked quite well so you may want to try that again.
FWIW emacs these days has native LSP support (eglot) and native tree-sitter supported, but you'll need to grab tree-sitter libraries and LSP servers. For MacOS I found just using brew to install most of these works great, and I wonder if Windows can't work the same way. If you're in a VM you should just be able to have your package manager do the work.
LLM support in emacs is still a bit primitive but there are packages like emacs claude-code that are changing things. Personally I wrote an elisp function which grabs the filename of the emacs window relative to the project root and copies it so that I can just paste it into claude code and have it ask questions or do things.
```
(defun copy-buffer-file-name-from-project-root () "Copy the relative path of the buffer in this project to the kill ring" (interactive) (kill-new (file-relative-name (buffer-file-name (current-buffer)) (project-root (project-current)))))
```
if you're curious but depending on how you have your clipboards setup with the kill ring, you may need to modify this.
---
As far as fighting the JS fight on the Zed website, well, I think this thread isn't one of those upvote-anti-JS-rant threads that spring up on this site all the time so shrug.
I'm extremely interested in pushing along these fronts even in a performative way, because I don't want to get bogged down in "switch away from Emacs" conversations with coworkers. I've done a lot of modernizing on my Emacs setup this year but I would love a current take on "getting close to cursor" that gets me beyond what I'd had set up with copilot and lsp.
Having tried a bit of Cursor and some Zed I still find Claude Code a lot better than the rest (though maybe now the Claude Code Zed Beta will change things.) That means what I'm mostly doing is keeping Claude Code up in the terminal and having it do things. Claude Code has an option to view diffs in your editor which you can configure and works fine with emacs and its various diff modes (and looks great too.)
I usually always make sure everything in my branch is committed before letting Claude Code loose on my code so I can view the changes normally as a magit diff and then choose whether I want to edit any of its changes (90% of the time) or commit as is (10% of the time.) I can also restore files selectively this way and have all of my git tools available if needed.
If you want deep Claude Code integration Cursor style, then check out https://github.com/manzaltu/claude-code-ide.el . The latest releases of emacs support using `vc` blocks to specify packages so you can grab the elisp package straight from the repo and get it working within your emacs.
If you want a chat style interface, GPTel exists but requires some config (not much but not zero either) before it becomes usable as a general chat tool like Claude Desktop or ChatGPT. I'm working on an elisp package to recreate a chat interface atop GPTel and decrease the config burden.
I mean, I am using standard Emacs daily for some 8y or so. It is just in that VM, that tried Doom Emacs, which crashed twice. Normal Emacs doesn't do that to me. And since I have the VM, I also don't need Emacs on Windows. The VM runs just fine.
That VM runs a Fedora OS and has vanilla Doom Emacs installed, with a few packages activated in the doom config. So it is about as vanilla doom Emacs as it gets.
The main reason I suggest running it natively is the big speed boost. Elisp supports native compilation now and native compiled elisp running natively on your platform is quite fast.
Lucky you because for me, for some reason, their website is randomly down when I click to change page: Web server (host) is returning an unknown error Error code 520.