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!
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.
The AI is a symptom of the problem. If it weren't AI, it would be something else.
Is that not what your employer does?
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).
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.
...and now they lose to a web app?
For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.
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.
That is a list of search results of people complaining that VS Code is slow compared to Zed.
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).
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.
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.
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
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.
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.
- Zed is not an electron app
- In the linked issue you can see that this issue does not exist in Electron.
Meanwhile on Linux and Windows, they still implement subpixel rendering so fonts look great on 1440p.
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.
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.
- 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.
Have Claude Code resolve merge conflicts, problem solved.
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.)
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.)
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.
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.
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 wonder why the startup time is slow though, may have to debug that one.
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.
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.
Memory usage of the IDE doesn't matter much when your language servers can eat 10s of gigs of RAM.
But the comparison here is broader than electron apps...
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.
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 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.
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.
No one ever closes emacs.
In this demographics, hype rarely is connected to technical qualities, they are used more as a post-hoc rationalization.
--- "Local QWEN": { "command": "/usr/local/bin/qwen", "args": [ "--experimental-acp" ], "env": {} }, ---
I have a subscription to Claude. What gives?
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.
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.
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.
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.
Internal error: { "details": "can't load supported slash commands" }
Tried restarting zed and restarting my computer, but neither resolved 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!
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.
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.
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.
If Zed would not exist, I would be using helix, neovim, or emacs as I did before.
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.
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.
Vscode has never had any input delay for me
It remains to be seen if Zed can avoid that though.
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.
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.
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.
Vanilla settings on a high end gaming PC.
Just try to use vscode on a ~500 dollar laptop from 2019 or something
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/
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.
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.
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 .
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.
>>It's smoother but...
Are you using an old computer or something?
VSCode has always felt ever so slightly sluggish to me, and I find it maddening as I type.
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.
Are you using Vim mode or something like that?
Fortunately standard editing shortcuts like Ctrl-D, Ctrl-left/right, etc. replace 99% of Vim "magic" and are way easier to remember and use.
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.
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.
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 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.
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.
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.
> Escape the Terminal
it does not sound like a good thing to me: a) the terminal is fine; b) AI should not escape anything.
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.
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.
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.
https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...
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.
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.
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.
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...
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 definitely easier with LLMs now, but still considerably hard.
But the team is out there ; )
commit b400449a58507cca1fa007197929c2cfd6beabbe
Author: Nathan Sobo <nathan@zed.dev>
Date: Sat Feb 20 10:02:34 2021 -0700
Start rebuilding with a cleanly-separated UI frameworkBeen wanting to learn Helix more and using it for small edits but never saw a Helix mode in any editor yet
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.
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
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.
then it's basically just a proxy for node/npm afaik.
https://zed.dev/blog/videogame https://zed.dev/blog/we-have-to-start-over
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 is literally their whole distinguishing feature and people are switching because of it and just it.
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.
> 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.
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.
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.
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.
Not quite there with emacs/vim but it's a much more accessible environment and more convenient for typical workloads.
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.
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 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.
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).
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.
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.
It is indeed a fine tuned Qwen2.5-Coder-7B
You mean an locally run OpenAI API compatible server?
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.
Glad it's working for you but I think you might be the only one!
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'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.
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.
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’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.
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).
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.
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).
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.
Agent Client Protocol (ACP) - https://news.ycombinator.com/item?id=45074147 - Aug 2025 (93 comments)
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 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.
I assume that keybind is also configurable?
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.
"New text thread" should also have no tools I believe.
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.
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'm getting ready to just switch back to Sublime Text
Zed's dead baby, Zed's dead
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 highly recommend trying fish, I wish I’ve switched earlier
- 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?
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've been seeing a lot of crashes of late
Which I didn’t notice until my whole balance ran out.
That wasn't stated or perhaps I missed it.
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).
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.
That makes the compaction summary a lot more focused and useful.
edit: But a work log/PRD is essential regardless!
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.
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.
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 can't believe people are ok with horizontally layed out tabs.
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: VC funded open source
- Sublime Text: indie closed source
None is ideal, but I guess we all know why.
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?
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.
I switched to gemini 2.5 pro, after some prompt tweaking nothing really beats in actual coding tasks imho.
I'm guessing claude code works roughly the same way?
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.
How do I configure it with Base API URL?
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?
koakuma-chan•3d ago
Aeolun•3d ago
adastra22•3d ago