Started using Zed about a year ago and, besides Magit, it has managed to completely replace Emacs for me. I was missing a good debugger for a long time, but that also went GA a month ago or so.
One thing that goes underappreciated is the input latency and how light on resources the editor is overall. Whenever I switch tabs to a web browser (or any web app), I can feel the lag in typing now, despite the fact I use an M3 Max MacBook Pro. Zed's built-in terminal used to feel high-latency too, but they recently shipped a bunch of performance improvements, and it's just amazing how clunky inputs feel in web apps feel after using Zed for a long time.
Two things I find interesting about this development.
1. This is a long-standing feature request ever since Zed added any AI capability. Adding AI-related functionality at all was a very controversial move at the time. See https://news.ycombinator.com/item?id=41302782
2. Text threads in Zed came out only 11 months ago. At the time, it felt revolutionary being able to effortlessly paste terminal output and entire folders into context. Additionally, being able to stop the LLM, correct part of its output, and have it continue code generation. Around 4 months ago, agentic coding released, and now this once-revolutionary workflow feels quite primitive. In the meantime, Zed also added screensharing, Linux support for collaboration, a Git UI, a debugger, and performance improvements to the editor.
I use Zed too, and as a longtime magit devotee, I've really been enjoying using gitu [0] in Zed. gitu doesn't have everything magit does, but there's not much I find myself missing.
I have it nicely integrated with Zed by defining the following task, which you can then add a keybinding for if you want:
Not currently using Zed but low input latency is one of the things that’s kept me on Sublime Text over the years. Might give Zed a shot and see how it stacks up.
The other two editors I use a lot are Xcode and Android Studio, and while the first is usually fine, Android Studio (IntelliJ) feels servicable but a touch sluggish in comparison. Given the popularity of JetBrains IDEs I’m a bit surprised that there’s not more demand from customers to make it more responsive.
They can definitely feel a bit sluggish navigating around once you have a giant codebase and you’re using a lot of features, but code editing has been very responsive for me.
I took Zed for a test drive about a year ago, and absolutely loved how butter smooth it felt to use. It's impossible to describe to others... you must experience it to understand what you're missing.
However, at least at the time, Zed's extension/plugin ecosystem prevented me from making the jump off vscode. Just like it took me a long while to ween myself off JetBrains and their workflow/plugins, it'll take a long while to do the same here - that's if an equivalent plugin exists (yet).
It seems to me, it would be a killer feature for new IDE's to just embrace vscode's extensions and make them "just work". It would remove a lot of the barriers people have with switching IDE's.
Maybe that's an impossible ask... I have no idea, but it would be pretty sweet.
I have not tried neovim, admittedly. Compared to Eclipse, IntelliJ, and now VScode, it's a completely different animal in terms of fluidity and smoothness.
Usually when I've attempted to explain it to others, people counter with things like "but my IDE already feels smooth", etc. I thought so too, until I tried Zed.
My only "complaint" was/is(?) the plugin ecosystem. It's a fairly new editor, so things might change in time.
These were the comments I came looking for. What existing users of Zed migrated from. I'm pretty curious to try it, but lacking some time to tool yak-shave at the moment.
You go to https://code.visualstudio.com and it will appear that AI integration is the whole point too. How a thing is currently marketed != How people have been using it.
I went from VS Code to Cursor, then got frustrated with Cursor breaking keybindings and other things, tried to go back to VS Code but missed the superior tab completion. Then I gave Zed a long hard try, but after over a month of daily usage I went back to Cursor again, just for the tab completion quality.
I don't use any of the chat or agent features, but for me Cursor's tab completion is a step forward in work efficiency that Zeta and Copilot were not. Sometimes it's subtle, and sometimes it is very obvious. Cursor seems to have sources of context that the others don't, like file names from the directory tree, and maybe even the relevant .pyi type annotations and docs for python modules. It also jumps to the next relevant problem site very effectively. It feels like the Cursor devs have done a ton of practical work that will be hard to match with anything other than a full-on competitive effort.
I want to see Zed succeed. I think it's very important that VS Code and its ultra-funded derivatives not dominate the modern editor landscape too thoroughly. Tab completion used to seem like a straightforward thing, but if the state of the art requires a very elaborate, whole-workspace-as-context environment to operate in, then I wonder if it's going to become a go big or go home kind of feature.
I can't help wonder what the actual internal API for this kind of thing is going to look like in the future. It used to be something like, what's the current token behind the cursor, and look in a big prefix tree of indexed words. Then maybe it got more elaborate with things like tree-sitter, like what's the incomplete parse tree up to this point. Then when editors started using AI, I stopped having any idea of what the actual inputs are. I'd love to hear about real implementation experience at any stage of this evolution.
I think we don’t talk enough about tab completion model quality. Recently Copilot’s model got a lot better (probably trying to catch up to Cursor) but I feel like there’s still so much room here (and I assume Zeds is worse from your description).
Smart context / big context is a really interesting question, I’m kind of surprised Google isn’t building here given how much effort they’ve put into big context (they have Jules and Gemini CLI but no tab completion UX).
On further thought I think one of the big 3 (OpenAI, Google, Anthropic) should partner (ideally not buy) with Zed to get a foothold.
For Copilot the quality of the tab complete is less of an issue for me than the fact that it is often very slow, or doesn't trigger at all when I would expect it to. I'll sit there feeling like an idiot for 10 seconds and then glance at the bottom bar to discover that it's not even doing inference, and have to randomly move the cursor, or delete and retype code until it finally works.
I have the opposite experience, tab completion by Copilot just got significantly worse for me recently (the last week or so), both for Rust and Python code.
I've been working on a better tab completion model that stays as an extension: https://ninetyfive.gg/
The main feature I really care about is low latency, which is my main gripe about Copilot. There's still a ways to go to match Cursor's quality but I'm chipping away at it!
I used Zed for about a year and a half exclusively, without using any AI features, and then switched to cursor to try AI features out. When Zed released its agent mode, I switched back to Zed.
I absolutely agree that Cursor’s tab completion is far superior to Zeds. The difference is night and day. Cursor’s really is that good. But the Zed agent mode works very well for me and Zed is, IMHO just so much better than an editor. I really hate having to use vscode or a vscode-based editor after using Zed so much (I used vscode exclusively before switching to Zed). And that’s enough for me to give up on the superior tab completion.
I hope Zed eventually improve theirs to a similar experience to cursor, but regardless, I love Zed.
nah, I've been using zed exclusively for a couple of months and Zed's agent mode is still worse than Cursor's, but I do agree the quality gap is smaller than on tab completion
I'm in a very similar position, using Cursor just for their Tab model. My ideal choice would be Neovim, but I can't replicate the productivity I have with Cursor Tab.
This is why I still use VS Code with AI features off and none of the AI integrated IDEs. It's not that I don't use AI. It's just that having the AI de-coupled from editor makes it much easier to separate concerns. Some days I don't feel like using AI and just need to edit one line. Other days I want to do a major sprint and test the latest AI and see if it will accomplish the task.
Zed is not a great modal editor, modality is a strapped on afterthought. At least that the impression the vim keybinding give me. IMO the best chance I see for a fast modal editor that works out of the box is Helix.
When did you last try Zed? If it was recently then that hasn’t quite matched my experience, for me vim keybindings work quite well. But I did think the same when I first used Zed over a year ago.
I tried it a couple days ago. Lost me right off with the poor `:e` experience; popup box with no completion, fuzzy-matching, sub-directory support. Vim is a file oriented editor, not a project oriented one, so good file operations are table stakes.
I don’t quite get what Zed’s emulation of :e has to do with being a modal editor. It’s a completely different editor so of course the interface to interact with files is going to be different, but in my experience Zed’s implementation of modality when it comes to its Vim mode is extremely good. Even better than the already excellent NeoVintageous for Sublime Text.
Fair point. I guess the problem is with their (Neo)Vim keybindings, not so much with the modal-editing part. I included it as vim is the most popular modal editor and its keybindings are what are lacking.
Are there any modal editors that are not file-based? Maybe it would be better to say this is a problem with its file-based editor emulation?
I at least really like that ctrl-w allows switching between panels as well as editors, something VS code doesn’t do (or at least, you can switch to the explorer but not back?) and is a major papercut IMO
Huh? Zed's vim emulator is one of the best I've used in an IDE. Saying it's an afterthought feels disingenuous. I'm pretty sure some of the core zed devs are big vim enthusiasts.
I don’t want to install 5-10 plugins with a hundreds of config lines just to make it usable. I prefer zed with 0 extensions and vim motions which are built in.
Not really, it installs even more plugins. Some of them are unnecessary.
Ideally, every time you update or install a plugin, it must be reviewed.
I just don't wanna deal with it and trust plugin developers.
I already got bitten by an infected Python library (that used to be legit). I treat plugins the same since they can be used in supply chain attacks.
You have to trust VS Code plugins too, along with trusting MS not using your code to improve their AI suggestions, or doing a sudden rug pull. All three happened if I remember correctly.
You can easily enable/disable plugins in LazyVim, and they are simple Lua Script/VIM scripts easy to review. I don't think VSCode would be that easy.
And even with more plugins, nvim/vim will be much more performant then VSCode.
I switched to Helix for the same reason. Though I'm thinking of re-trying with one of the lighter weight pre-configured versions. Astronvim seems like the best one after a bit of weekend research.
The one thing I love about VSCode is how trivially I can fire it up on a container or on a remote machine via SSH. If Zed had this I would switch tomorrow.
So my question for Zed users is: does it?
The UI is a tad idiosyncratic on Linux (can't speak for Macs) but DAMN is it fast, I love the generality of tasks.json (haven't played with debug.json yet), by far the best system I've ever used, and everything just works well out the gate.
Zed has SSH editing. But when I tried it a couple of weeks ago, their in-ui git didn't detect a repo in a folder that very much used git, and ports you want mapped have to be specified ahead of time, there's no way to do it at runtime like in neovim/vscode
I've wanted to try Zed but I'm generally antsy about tools unexpectedly phoning home -- haven't had a chance to closely evaluate myself.
A few tinfoil-hat questions: I know obviously it needs to phone someone to use functionality like remote dev or certain integrations, but outside of those situations, does it otherwise perform any kind of telemetry by default? Are there situations where it could ship off tokens in files I'm editing to some remote server where one wouldn't be expecting it? Also, I know it's open source, but is it meaningfully open source in the sense that the prebuilt binaries available for download in the obvious places aren't some reskinned proprietary version like is the case with VSCode?
These are meant in good faith -- genuinely interested and curious
Zed seems really nice, and the usability has come a really long way in the last couple of months. That being said, I have one issue, and I hesitate to even bring it up because it seems so shallow: I hate all the themes! They all look so ugly and amateur. I know this is a really trivial thing, it's like complaining I don't like Python because it uses whitespace for indent or something, but I just can't get over it. VSCode/Cursor is beautiful in comparison.
I recently found Github Dark Default, which is probably the okay-est of the 10-15 I tried, but there is so much that still looks bad. The autocomplete popover looks far worse than VSCode, the file tree looks much worse, tabs look ugly, etc.
You're not alone. The only reason I struggle to onboard to Zed is the design. They're doing an incredible job with the editor, but I have never seen a more bland design in any IDE. It's genuinely so bad that it affects my productivity in it. I'm a fan of Visual Studio and VS Code dark themes, I don't need anything special.
Isn't "bland" design precisely what you'd want from an IDE? To help you focus on the code and all that?
It's been a while since I last looked at Zed, so I just started it again, and it ... looks like your average macOS app? Which to me sounds pretty much ideal.
Nothing wrong with bland, but a well-designed IDE does a good job using the UI to allow you to parse information as fast as possible. For instance, compare the autocomplete popover in Zed to VSCode. The VSCode popover:
- Has icons. These are so useful for parsing information quickly!!
- Shows the type information in a different color than the field name. There is spacing between the type name, and the type is smaller.
The Zed autocomplete popover is a solid wall of (almost entirely) monochrome text, all the same size. It is significantly harder to parse. I use the autocomplete popover probably thousands of times a day. These subtle things make a big difference.
Is the Zed popover bland? Yes. Is the VSCode popover flashy? Not really, it's just utilitarian - clearly designed by someone who understood how important every detail is.
I program mostly in Rust, so in theory Zed should be the perfect IDE for me. But I couldn't get past the design. It just put me in the wrong mind space.
As a data point for the Zed folks: JetBrains' RustRover with vim key bindings is still my go-to. It just "looks and feels" right to me.
I'm sure that they'll get there in time. They're playing the slow, careful, methodical game. Writing it in Rust was the right choice and it'll pay dividends.
In 2007 I had the best actionscript IDE that looked awesome and made the whole actionscript development magical. FlashDevelop iirc. It made a huge difference and inspired me every time.
There's a forum thread [0] where users share their custom themes.
There's also an importer tool [1] that lets you convert any VS Code theme to a Zed theme. You might still need to compile the importer yourself, but it's all pretty straightforward.
I agree. I couldn't get over any of the existing themes, they just seem so low contrast... So I spent a bunch of hours porting then favorite theme I've been using in Sublime Text, to Zed, named iPlastic. Sublime Text has a theme back of classic TextMate themes, and it came in that pack. I have to say, the porting process was not very easy, but it was worth it. Now, I prefer Zed to ST and VSCode because of the theme, not just the UI and other features :)
I use the Night Owl theme in all my editors (and terminal), including Zed, and the consistency is nice. It looks good, but if there’s a Zed-specific issue I haven’t used Zed in a while.
I feel you. I still haven't found the light theme that would work for me. In VSCode I use Better Selenized. Even tried to import it to Zed but experience was a bit subpar.
The thing that's so sticky for me with JetBrains IDEs is their run configurations. Being able to configure all of the environment variables etc. for the actual code that I need to run, especially when connecting to a debugger or tests integrated with the IDE.
I haven't seen anyone else complain about this so I figure I must be missing something. Does Zed let you set up run configurations like this? If not, how do users actually run their code? Just in the terminal? It seems backwards to me to use a fancy IDE, but then run all your code in the terminal. I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
> It seems backwards to me to use a fancy IDE, but then run all your code in the terminal.
Having literally spent days at a time just to get a working run configuration at various employers and clients over the past decade, I find it backwards to use anything besides the terminal and version-controlled scripts & task runners / CLIs to fire up anything. (: People rarely document their JetBrains setup fully and even if they do, JetBrains IDEs are not exactly known for their reproducible behavior or for not occasionally messing up your configuration (in case you do decide to check in your IDE config & share with your team).
Besides, you will need those terminal scripts for your CI pipeline, anyway.
That being said,
> I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
I agree, that is very useful. However, to me it's the cherry on top of proper self-contained run scripts for the terminal.
Points taken about benefits of run scripts for portability, reproducibility, CI, etc. I'm mostly just trying to find a way to debug arbitrary programs and run tests in the IDE.
Maybe my use case is too specific, but I'll spell it out just in case: I try and open a Django project in Zed. I go to a test file. There's a > arrow next to the test to run or debug, but it will only run it with PyTest (I use unittest, but PyTest is backwards compatible, so w/e). When I try to run it, it fails because some environment variables I need are not set. I don't see how to configure them so I'm dead in the water.
I'd also love to run the Django server with a debugger attached. It's not clear to me how to do that. I haven't found the rights docs. Dead in the water again.
Maybe I need to spend more time exploring and reading the docs :)
Same here. Zeds task configurations are not nearly as versatile, easy to set up and run as pycharms especially when it comes to virtual envs. The debugger is superior in Pycharm too. But in terms of overall use Zed is good.
My other complaint is that pyright (used by Zed) isn’t nearly as good as pycharms type inspection.
I love these too. I have a run config checked into my repo that runs three run configs, for `fastapi dev`, npm start, and launching a JavaScript debugger, with one click. I also like clicking on a test or script and just hitting "ctrl+shift+d" to launch that particular code with the debugger.
VS Code can launch a fleet of dev containers but it's just not as good of an experience to restart and debug.
What I'd really like is an option to disable the automatic multi-buffer behavior for things like git diffs. It just doesn't work for me, and the Zed UX seems to not even realize that not everyone will love it.
The multi buffer is the most amazing thing about Zed. AI be damned. It now feels wrong to use an editor that doesn't have it. It is so obvious in hindsight.
Honestly, this is a weak point of Zed IMO. I just find it a bit confusing to deal with. I don't know exactly how to get it to jump to the location of a specific block in the multi-buffer view, e.g. a Find in Files view. I double click various places in the UI until it goes to the file and sometimes I have to scroll to where I was at in the multi-buffer view. It's very frustrating.
I think it could be made to work better, but as it is now, it feels cumbersome to work with.
Took me a bit to find this, but you can click on a line number in multi-buffer to open that file at that location. I think their default assumption is for you to not use the mouse much.
If you're using vim mode g+[space] will open the file where your cursor is. I think it's alt+return in normal mode but either way there's a shortcut hint on the right side of the header for the file your cursor is currently in.
I think this is one of the best innovations in Zed, though it could use some more polish to work really great. Being able to edit the diff directly surely is a great thing?
The problem is that it insists on jamming together all files in the list, each with only a tiny bit of context, when I want to look at things one at a time with full context, and there's no way to change that behavior.
Sadly, I came back to using VS Code recently. There's a lot to like in Zed but imo that decision to write their own rendering framework is unfortunate, because of ridiculous problems in Linux still not resolved like poor font rendering, especially on low-DPI screens, or visible lags of UI which is being developed to be blazingly fast. So far, VS Code is faster for me.
Remember that Zed hasn't reached 1.0.
On other platform, it is much faster and consume much less battery. Just like ghostty, to me the most attracting feature is knowing my editor/term is not backed by a browser engine.
> the most attracting feature is knowing my editor/term is not backed by a browser engine
How and why is this important? At any time I have two browsers with dozens of tabs and on top of it a slack client active, how another instance of a browser engine could hurt in this mad world?
try it and found out; it's not about memory overhead (maybe it is to someone), it's that it works so much better than web backed things. it's just an absurdly fast/responsive/delightful thing to experience after years of everything going the other way [while hardware actually gets faster]
and i say this as a proud career long web developer. i just really like zed.
Zed was my daily driver for almost a year. When it's working fine and not drawing the mouse cursor at 3 FPS it feels pretty much as anything else in terms of perceived speed. I saw mentions that you need to be younger to notice the difference. Like you don't hear frequencies above 18 KHz if you're more than 20 years old. I get the idea, I just don't see where it is connected to my real world experience
As a quick anecdatum, I'm on macos and I'm definitely more than 20 years old, and there is a quite perceptible difference in responsiveness between Zed and a VSCode-based IDE for me. (Though then again I did play fast-twitched games a lot when I was younger.)
I listened to a podcast interview with one of the cofounders of zed. One of the revealing things is that he went on and on about how important latency was and how they had to do their own rendering because of the problems they ran into with electron. He also admits that he never used vim, which already has imperceptible latency relative to the terminal emulator, which has already largely solved the text rendering problem.
I understand that there are advantages to being a native app from their perspective, but for me, it is even better for my editor to be integrated into my terminal editor. And because they built it the opposite way though, they have to also build a terminal emulator into their editor.
There is a real cost to building zed this way. If they were an embedded terminal app, they would get full terminal support for free and would not have to implement 2d text rendering. They could even have made a bundled package with an oss terminal emulator like kitty. Then they could have focused strictly on their editing features and value adds. Every engineer hour spent fixing bugs/adding features to the rendering framework is an hour that could have been spent on value adds.
Personally, there is no way that latency itself can be that value add for me because I use neovim and don't use any language plugins so every keystroke already renders instantly. Clearly then you can do everything zed does in a terminal app within at worst tens of milliseconds of latency.
Of course their target market uses vscode and not vim and either doesn't know or care that you do not need to write your own rendering engine to make a low latency, featureful text editor. I am admittedly very much not the target consumer for zed though.
Learning and wanting to use as a daily driver are very different things.
I use vim on my servers and for writing git commit messages. For everything else, I use another editor (used to be Sublime Text, then Vs code, now Zed).
Nailed it. I'm fine with using vim to do remote work. I'm not an expert, but I have enough muscle memory to zip through the things I need to do. I don't want to use it exclusively, though. Turns out I'm capable of learning my way around multiple tools and using different ones in different contexts. Who knew?
I don’t say I don’t know how to use one. I was a longtime vim and then neovim user. But I don’t want to use one.
I still use vim for quick terminal edits, git commit messages, and doing stuff over ssh. But for my day to day heavy text editing, I do not want to sit in a terminal and be limited by what a terminal can display.
I seem to hear this a lot, but there's probably like 10 commands (maybe a few more if you want to be fancy with copy-paste). Note: great if you like nano however!
For those that are interested, this will get you 90% there:
+1 I've explored Atom when it was the hot thing, and more recently, an IDE called Lapce, which is built in Rust and doesn't use Electron.
They've been great, but the lack of an ecosystem stares glaringly right at your face. I don't like Electron apps but VSCode gets the job done.
I have my entire set of plugins and things installed here and now the productivity that I get off this setup even exceeded my long-loved Jetbrains IDEs. I hope that will be temporary though, seriously.
The only thing that I strictly dislike about VSCode is the number of high quality themes available - and there are not that many.
Recently stumbled upon VSCodium which is a clean VSCode fork that can work with any VSCode plugin, but I am yet to try it out.
I miss Atom. I loved it. I loved all the crazy plugins people would make to do all sorts of things. It was a fun time.
These days I'm stuck on QTCreator most of the time. It's OK for core editing functionality but there's a lot that I miss, and some things like the generic Language Server support just aren't fleshed out much.
I'm tempted to use another editor whenever I'm not working on UI files but it adds some friction.
> VSCode fork that can work with any VSCode plugin
Technically yes, but if you care about legally, you can't use extensions from Microsoft's marketplace, which excludes Microsoft's own closed extensions such as WSL/SSH/devcontainer remoting and Pylance. It ships with Open VSX instead.
I use it on Linux and think it's great. My laptop has a screen with some crazy-high DPI and a monitor which doesn't. Changing the font sizes in settings to suit has never left me with a poorly rendered view.
Same experience here on Linux, where bast majority of potential users seems to be in Linux who loves vim mode, Zed's focus on Linux is pretty bad. I would say alpha quality at this point.
I appreciate this option since I use Zed without AI. However, their overwhelming focus on cramming AI in the editor just disappoints me. The core experience is still very raw and there are small things that build over to make it annoying.
I still have Sublime Text as the backup editor. It's lack of a powerful sidebar and search are the only things that stopped me from using it regularly.
I do use VSCode at times and the CoPilor powered tab completion (which mostly hallucinates and spits out nonsense) is just obnoxious. I've found JetBrains' implementation of full line completion and block completions a lot more thoughtful and reliable.
Just wanted to say thank you to the Zed team for listening to this bit of feedback! I'm very much of the opinion that AI is not a value-add, so I appreciate the ability to disable it.
Disagree. The tab completion is very annoying when you’re trying to type. I know, I know, AI hipsters think typing code is so 15 minutes ago. Get off my lawn/keyboard.
Its agent AI assistant isn’t bad but sadly the restore points button in the AI panel seemed to be broken.
The fact it reminds me of sublime text is a big plus for me.
The rust evangelism is annoying. Really. No one cares what language a program is written it.
> The tab completion is very annoying when you’re trying to type.
I think it is annoying if it completes it by itself, but tab completion can be helpful if you have to push the tab key (or whatever other key is mapped to autocompletion) to make the completion to work (although I don't need LLM to do tab completion).
In most code editors, hitting tab increases the indent even if you are using spaces (e.g. it will add two or four spaces). But now you don’t know if it will increase indent or arbitrarily rewrite your 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. In cursor, it’s at least 80% of the time jumping to the next thing I was going to do anyways. (Example: I add a function call, and tab recommend jumping to the top of the file, importing the function from the right spot, and then jumping back to the call site. Example2: I change a function signature and update one call site. It then correctly auto-completes the 5 other call sites to match the new format.)
both of those examples (auto imports + refactoring) 'just work' in Jetbrains editors, and have for a decade, without any AI at all! and you have the added benefit of no hallucinations when doing a refactor across hundreds of KLOC
Disabling JS is incredibly beneficial for browser performance, battery life, privacy/tracking protection. As an added bonus, it protects you from malware from all the vulnerabilities in Javascript engines.
Which vulnerabilities in the past few years were actually used as a way to propagate malware (Not targeted 0-days)? Even with a JS engine vulnerability, you'd still need a sandbox escape to do something useful with it
Most of the vulnerabilities I've seen that could infect your machine from a website require JS to work and most of those had nothing to do with the engine itself. Sandbox escapes are extremely common. Chrome patched one that'd been being actively exploited just last week
It also makes a lot of basic features on websites unusable. Just an HN vote uses JS. They deliberately added a fallback to work without it too, which most websites won't do, but it still has to reload the page.
Because of my job I end up browsing the web with JS disabled by default and 90% of the time I don't need JS at all. Most of the time there are features of websites that break/don't work (menus, search, videos, ads, etc) but the actual thing I went to the website to get works just fine. In fact, pages load much faster and look much cleaner!
There are some annoying websites that can't manage to display simple text or even a basic image without JS (which is just bad web designers doing bad web design) and some instances where the content I need is obscured by something that doesn't behave without JS (like an expanding menu spewed out all over the place because JS isn't there to hide what hasn't been selected/hovered over) but in those cases it's usually just 2 clicks to solve the issue (either for just that visit or for every visit to that domain in the future as well) so it's not really a big deal. I'm currently using HN without JS and it's great.
A friend of mine created some business plans to help organizations migrate from cloud infrastructures back to on-prem solutions. Like AI features, the sweet spot is somewhere in the middle: hybrid has its place instead of cloud-only, and AI features have their place instead of "everywhere."
what if that setting were an enum every operator started with AiMode::Off so we can consciously opt-in, plus then Zed could have more AI Mode levels besides just on or off?
Maybe there could be a level for experienced programmers and another level for vibe coders, and prompts / permissions could be set accordingly?
That's basically the case when you have AI mode on in Zed today.
The four AI features in Zed (that I'm aware of) are:
* autocomplete -- this can be turned on and off separately from the AI features toggle, and can be put into 'subtle' mode, where you have to hold a key to see the completions.
* inline AI editing -- only activated by hitting ctrl-enter, otherwise you'll never see it.
* agent/chat editing -- you can disable the right-side chat panel, and you'll never see/use this.
* AI generated commit messages -- there's a button you hit in the commit message panel to activate this.
Zed has been moving fast lately and I can almost use it full time, but no git log and poor git diffing has me frequently clicking out of it. They are spending a huge amount of dev time on AI features instead, so this is a nice feature, but it still doesn't change their focus.
I used Zed a decent amount before it started being too in-your-face with AI features. Glad to see an option to disable it all, but at this point, I’ve become so much more efficient with Helix than I am with any graphical IDE. I wouldn’t love to go back.
I did 4 months of Cursor. Figured I’d try 4 months of Zed, and see from there. I’m about 3 months in and so far might stick with it. I’ve generally been pleased with it. My only issues really have been
a) all the settings are just in a file, not even a commented skeleton, and with a decent change rate, hard to invest in learning them; I’d love something like the jetbrains settings dialog
b) the stupid placement of the burn mode button; it’s so easy to accidentally turn this on and not realize (done it twice now). Would love an option to just remove said button
c) I wish there was more panel control; I’d like to place outline and project views BOTH in a panel, but you only get two full height tools in the left/right panels.
Other than zed.dev being down for the first time since I started using it, I’ve been manually disallowing AI connections from the get-go. What’s different? What wasn’t I disabling originally? Is this just a shortcut to other options?
"Some developers have fundamental objections to AI in their coding process—whether it's concerns about training data, environmental impact, or philosophical reasons about machine-generated code."
not only that, there's the "jesus christ fuck off" angle. Stop bullying me into using AI when it serves you, not me. Every goddamn surface wants me to click on their "write your email like a fake idiot" button because they get to report X% WAU uptick which is supposed to vaguely correlate with revenue/growth somehow according to some stupid metric. But no matter how much you can twist reality to justify it financially the fact remains that shoving features in your users' face is not the best user experience you could have made, because you could have not done it. Good designers (...picture your platonic ideal of Jobs-era Apple, not that it was actually perfect but it was better than this shit...) would never do that. If only we lived in a world where there was enough market pressure to annihilate a company for designing things badly---unfortunately no one is competing on that angle yet (big opportunity, imo). In the meantime we just have to ask, nicely and then angrily: please, god, fuck off. It should not take angrily asking, or finding leverage, in order to get you to be respectful. You should be respectful by default.
Weird that it wasn't optional before, right? Not sure if this is related to the recent stories of AI agents nuking people's code, but that's just one more reason to make it optional.
My problem with AI in Zed is not that it's there, but that it feels like it's always behind in AI code editor paradigms. They were pretty late to the party to add edit predictions, and their agent UX is pretty behind the game. Recently, Cursor added background agents which I feel is a game changer and I now feel it's a deal breaker when choosing an editor.
It makes me wonder if choosing to build their own GUI framework in Rust was the right move. Zed is a great code editor, but for me, it's not a great AI code editor.
- Upgrade our NodeJS version because it just got deprecated
- Upgrade our linter to the newest version, add a new rule, and fix all instances of that rule in our code
- Make minor changes to our UI
- Fix small bugs that I know how to fix, and can tell it exactly what to do
The main pain point they're solving for me is that I have many small tasks I need to do. Coding them isn't the main bottleneck, but creating a new branch and then creating a new PR is the main bottleneck for me. With cursor specifically, I don't even have to check out the branch locally to verify the code.
For any significant work, I'd rather manually do it in editor.
Maybe this is a pedantic nitpick, but I do wish the feature was "disable_llm" or similar.
The term AI is so poorly specified today, and while I don't want my editor using LLMs to predict my next keystroke I do still like the more basic auto complete features.
For what it’s worth, I would really like to have an iPad version of Zed that I could use the remote function into my Mac and homeserver via Tailscale and be able to code on my iPad.
I want this in Warp. It's a solid terminal, but Claude Code is so good that I don't need my terminal trying to do something similar without me asking it to.
Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true?
Are there some mechanical semantics I'm missing here that make this beneficial?
Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.
Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.
Enable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?
First of all, enable/disable is a dichotomy, and is not a set of two dichotomies.
Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.
In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.
Imagine for example you're in a court of law. Which one sounds more damning?
=======
Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?
Defendent: But Enable_AI just means enabling the use of the output!
====
====
Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?
> Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.
Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.
Well, I do feel a distinct connotational difference, but then again, I could be the only one I suppose. And if the average person doesn't care, then why argue about it at all? And how many average people will be using Zed anyway?
My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)
If it was just CGO=true or CGO=false I think so much confusion could have been avoided.
I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.
> It's set to 0 or 1 to enable/disable (can never remember which mapa to which)
That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.
This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies.
I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?
I don't think me writing an if condition
if boolean != true
instead of
if boolean == false
should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.
Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.
Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.
I always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_DISABLED, MOCK_ENABLED, etc.). I thought env vars are always considered optional by convention.
IMHO flags like this should always reflect the planned steady state. If you plan for a feature to be on in general, then the flag should be a disabling flag that eventually goes away.
It's good and predictable that all boolean settings to be false by default (when not set). And the default behavior is the one that is compatible with older version — changing the defaults is a breaking change that should usually be avoided.
Yes, this is especially useful if the boolean settings are stored in a bit field, in my opinion. In the case of Zed, according to the article, it uses JSON, but if a program uses a bit field instead then it would make sense.
How long did it take for you to get used to the autocomplete?
I completely hated it when I tried it out. It breaks my flow. Those weird pauses are so painful. Feels like someone grabbing the steering wheel while I am driving.
I heavily use the agent mode but I don't understand the appeal of the autocomplete feature but maybe I am missing something.
You spent 20 years without autocomplete? I started using Eclipse's autocomplete & shortcut macros in 2002.
It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.
AI autocomplete can generate the entire `match` tree for a very complex Rust enum, and also generate all of the associated tests. It then takes me to the next places in the code where changes need to be made. It's wildly good at knowing exactly what I want to do next.
2002 macros and autocomplete were not that and cannot possibly be compared in the same light.
Zed has everything I want out of an editor, the AI stuff wasn't really a concern to me since its always been optional, but I fully appreciate where they're coming from. I think Zed is one of the good gems of our time. I have been looking for a decent spiritual successor to Sublime, and Zed to me is really good at it.
I moved to Zed last week and its been amazing so far! Something about using it feels a lot more crisp and fast compared to vscode. Their AI integration is pretty decent too. But I am very glad I can disable AI now. I find AI sometimes takes me out of the flow because I am constantly reviewing its code.
Meanwhile (at least from what I've heard from friends), VS Code is pushing for users to use Copilot more and more. I'm glad I jumped to Zed a few months back.
I'm glad they decided to add this. I still want the ability to disable all the account login stuff part of the UI. So i hope they make that as an option too. Since, I don't like signing into my software.
"Even if you're skeptical [of genAI], these tools are quickly becoming part of how software gets built."
Yeah, well, you know, that's just, like, your opinion, man.
I am thankful Zed added this feature and most of the post seems reasonable, but it's still the height of weird that they feel compelled to say this—obviously it's not how software gets built by the people who are avoiding these tools intentionally and for good reason!
Especially given the recent study that found people felt more productive while objectively getting less done.
It's like saying, "marijuana is rapidly becoming a part of how people get through their day, but we understand not everyone wants to spend their day high."
Zed has been nice, but I really miss the fuzzy search (files and grep) with live preview - something like telescope in neovim. The search results in zed feel super clunky to navigate through.
This gives me hope they might fix collaboration too. Unfortunately had to switch to VSCode Liveshare (which has its own problems) a few times because Zeds collaboration was so broken.
Love this. Prefer deciding feature by feature basis, but in a world where everyone is ramming AI down your throat with a jackhammer and compulsory ToS this mindset is welcome
I am really, really starting to like Zed. I noticed recently that it now respects my EditorConfig files, which was one of my biggest gripes before recently. In general almost everything that I didn't love about Zed has been fixed.
I have only tried it a couple of times, but Zed's AI assistant view indeed works as promised, doing about as well as Cursor does.
Now there's just one thing that is a bit annoying... It's kind of heavy on the GPU. I mean it looks and runs great, but it really loves to suck the battery out of a device that's running on battery. But frankly, I've been ready to ditch text editors based on web browsers basically since they became "in vogue" and have just been waiting for the right thing to show up. As time goes on, I think it becomes more and more obvious that Zed is "the right thing".
I don't know if there's anything we can do to make sure Zed succeeds sustainably and doesn't eventually get enshittified, but I'm crossing my fingers that for once we can have nice things.
Re GPU usage: noticed this myself a few months back and decided to poke around. Recommend turning off the minimap if you have it enabled. There seems to be some over-rendering that is exacerbated by it. It's actively being investigated and improved upon (0.192 was a great step in the right direction) but, even still, I've found it (currently) has a big positive impact once disabled.
It hasn't been a huge deal: I'm still getting a decent number of hours doing work on battery on my Framework 16, and usually I can plug into AC for a little bit if it gets too low. That said thanks for the information; I'll have to keep it in mind.
> I don't know if there's anything we can do to make sure Zed succeeds sustainably and doesn't eventually get enshittified, but I'm crossing my fingers that for once we can have nice things.
This is a good conversation to have. We can start by pointing this out and encouraging broader interest. Zed has been my daily driver for over a year.
I'll make a claim -- does anyone disagree (?) -- the incentives are not pointed in the right direction. Unless developers are paying directly for the functionality they want, that's misalignment. So enshittification seems probable, maybe inevitable, unless something structural changes.
OTOH, because they charge for their editor, JetBrains has incentives that are better in line with customers.
> I'll make a claim -- does anyone disagree (?) -- the incentives are not pointed in the right direction. Unless developers are paying directly for the functionality they want, that's misalignment. So enshittification seems probable, maybe inevitable, unless something structural changes.
Exactly.
AI autocomplete I just don't care about. OK, but they do offer an AI subscription service. I'm using LLMs almost not at all currently, but at least right now this does seem like a viable path to getting a lot of money. I worry, though, that in the long run, the margins will just get squeezed by competition here, especially when a lot of deep-pocketed competitors can charge nearly nothing and get away with it. Zed also very nicely offers the ability to drop in an API key for their AI agent features... which is awesome and the right thing to do, but not good for profitability.
Obviously, the issue with simply charging money like Jetbrains is that Jetbrains already has built a world where they have a super complete IDE package and even then they only really charge a relatively small amount per month for the privilege. It works because for software the development costs for a given piece of software is relatively "fixed" (not entirely, but close enough) whereas the revenue you get grows as you acquire users. But now that the market is saturated, it's going to be hard for someone to jump in and try to be like Jetbrains in any way, and if you're charging money it's even harder to compete with most of the other code editors that are ~free.
Worse, it's hard to charge money and remain completely open source. Linux users will mostly not even realize you're doing it because the packages will just keep working for free since the software is open source. And Zed really does benefit from being open source, maybe more than many other open source offerings; it really seems like the community did a lot of work on making Zed work well on Linux. (By the way, if any of you who worked on the Wayland support for GPUI happens to read this, thank you very much for the excellent work.) So it's hard to say "just go closed source!"
I hope Zed Industries got a good deal on whatever funding they received and are being somewhat conservative with their funding too. Even though it's hard to compete in this market, they've built something that is very hard to build and basically not paralleled as far as I'm concerned. There's clearly something here and finding a less shitty path to monetizing it would be very, very good for us all.
(And I am willing to pay, though I know they need to find something that will make a lot of people want to pay, not just people like me.)
Maybe a year ago (or couple of months ago, I can’t recall) but I found out about Zed and since I was learning Rust, I wanted to contribute. But then I saw that they have a CLA. So while it won’t be easy to go closed source and not upset their users, it definitely is possible. Any contributions, no matter how important, are already covered by the CLA.
Ah yeah, they have a CLA that forces you to give them a carte blanche copyright license to contributions and they also restrict dependencies to be ones with permissive licensing too.
Pretty obvious what's going on here. I hate seeing it happen, though.
FWIW, we plan to sell "enterprise" builds of Zed with SSO, centralized plugin repositories, business-hosted infra, etc. etc. The sorts of features developers don't care about but businesses do. To do that, we have to be able to re-license the codebase and apply these changes. We have a lot of other ideas for business sustainability but the core, offline code editing experience will always be freely available and open source though :)
I don't really expect you to respond but if this is true why not use a CLA that guarantees the code stays open source? The FSFE FLA exists and is prominently used (though optional) by KDE.
Hey - I'm the founder of WorkOS. Happy to chat about the playbook we see with OSS projects spinning-off a commercial offering. It's pretty common and we work with a lot of these businesses, enabling them to continue investment in the ecosystem too. mg@workos.com
Taste and empathy maybe, but their choice of licenses, technologies and priorities can still be juvenile to the point of sinking their company.
Just look at the amount of excitement in their industry right now. New IDEs are springing up practically by the week. Are any of these new IDEs based on Zed?
No, of course not. GPL closes the door on that, and who would want to own a fork of a tool that's so painful to develop? Developers working on VSCode can probably do an average dev-test cycle in 1-5 seconds. I've no idea how long the Zed dev-test cycle is, but I hear Rust builds are notoriously slow so I assume it's more like 1-5 minutes.
With the help of subsecond[0], we're seeing <1 s dev-test cycles for changes to Rust GUI projects these days :) That's with a fast CPU and optimized compiler settings, but it's competitive with things like Flutter and the web stack.
Even without hotpatching, Rust incremental compile times are on the order of 10 seconds, not multiple minutes. Clean compiles still take minutes, but that's a "once-a-week" workflow usually.
Not sure if Zed has gotten it hooked up yet, but things are changing rapidly in the Rust GUI (and games) space because of Dioxus's innovation here.
Thank you for educating me. I don't actually work with Rust so I shouldn't be spreading misinformation about it without knowing what I am talking about.
It doesn't really change my multitude of problems with Rust as a language for a project like Zed. Zed feels like a cathedral to me in the Eric S Raymond sense. Rust feels like a language for building cathedrals. Javascript is the language of the commons, which is why the idea of a hackable IDE in JS was so brilliant. Somewhere along the line the team forgot what made Atom great (despite its flaws).
Yeup, this exactly. If they're going to be allowed to use claude-code/copilot day to day, how well they review the ai-generated code is going to be huge signal, as well as they could explain what happened. Also, if they're jsut blind vibe-coding something, without creating a nice quick spec for the LLM, that would also be a signal. Also, makes for very easy follow on questions during the interview.
Yeah! Fast, good looking, no AI integration, ability to turn off blinking cursor and customize, and paying for it supports a small company in Australia rather than a huge, soulless megacorp.
> code editor [with] high-performance collaboration with humans and AI
When investors are involved this immediately changes to:
> Our goal is to build a product which will hopefully return more than our financial investment.
I get the feeling many HN contributors to this discussion forget that Zed is not a software project like Neovim, Nano or Emacs (etc.) which rely on donations and/or sponsors to either pay developers or cover required infrastructure costs.
It's a product backed by investors who - one day - will demand their pound of flesh, and "features" like AI are added to market the product to _more_ investors.
Perhaps the use of AI itself inside the product will also be tracked to steer potential opportunities for the investors themselves.
Like many fellow HN'ers, I use Zed on a daily basis, and it's no different than Google search or Facebook - "If a product from investors is free, YOU are the product"
good one. Just yesterday It got me to a point that I can't stand ai forced auto completions in vscode that I ended up whole copilot extension.
It's too distracting that Ms forcing too much on AI
I tried Zed many times. In fact I try to use it at least once a month because it is indeed fast. However, I just think it’s a half-baked product and I don’t want to invest too much time into it. Wish they didn’t get distracted by AI and focused on making a viable VSCode replacement as an IDE/Editor.
I mean all good but I still wonder if building an editor is really sustainable you basically only fight for new coders everybody else will just stay with vs or IntelliJ because of muscle memory
I know you can share keymaps but it never works 100%
Like I must’ve been tremendously more disappointed with my current ide to even consider switching
Counterexample: I went Sublime Text 2 -> ST3 -> Atom -> VSCode -> Zed, and every time barely noticed a difference in editing experience. The keymaps were >95% compatible after each of these switches. But I guess that was the happy path given these editors share lineage.
OTOH I was never able to switch to Jetbrains IDEs for long, because everything was too different, even after installing compat keymaps.
> Even if you're skeptical, these tools are quickly becoming part of how software gets built. Understanding them helps you make informed decisions about when and how to use them—or not use them.
What? Blockchains and Web3 again? Oh no wait... AI
What is the point of this? Surely anyone who (correctly) has moral objections would require a fork getting rid of the code to support it entirely, not just a runtime toggle?
There are more reasons than moral objections one might not want to use the AI features in Zed. The post gives a few concrete examples but I think this sums up the general situation best:
> Zed is built for engineers who care about their tools. That means giving you control over your development environment, including the choice to work without AI if that's what works best for you.
That's true for this and many other features of Zed. For example, telemetry can be disabled with a simple switch. However, I feel deeply uncomfortable knowing that my editor is ready to report every file I open, commit I make, code action I perform, etc. at a moment's notice, held back only by that one line in my config file.
If you have a moral objection of enabling that feature, you might or might not also have a moral objection of the program having that feature, so I think not everyone does.
Started using Zed about a year ago and, besides Magit, it has managed to completely replace Emacs for me. I was missing a good debugger for a long time, but that also went GA a month ago or so.
One thing that goes underappreciated is the input latency and how light on resources the editor is overall. Whenever I switch tabs to a web browser (or any web app), I can feel the lag in typing now, despite the fact I use an M3 Max MacBook Pro. Zed's built-in terminal used to feel high-latency too, but they recently shipped a bunch of performance improvements, and it's just amazing how clunky inputs feel in web apps feel after using Zed for a long time.
Two things I find interesting about this development.
1. This is a long-standing feature request ever since Zed added any AI capability. Adding AI-related functionality at all was a very controversial move at the time. See https://news.ycombinator.com/item?id=41302782
2. Text threads in Zed came out only 11 months ago. At the time, it felt revolutionary being able to effortlessly paste terminal output and entire folders into context. Additionally, being able to stop the LLM, correct part of its output, and have it continue code generation. Around 4 months ago, agentic coding released, and now this once-revolutionary workflow feels quite primitive. In the meantime, Zed also added screensharing, Linux support for collaboration, a Git UI, a debugger, and performance improvements to the editor.
I use Zed too, and as a longtime magit devotee, I've really been enjoying using gitu [0] in Zed. gitu doesn't have everything magit does, but there's not much I find myself missing.
I have it nicely integrated with Zed by defining the following task, which you can then add a keybinding for if you want:
[0] https://github.com/altsem/gituNot currently using Zed but low input latency is one of the things that’s kept me on Sublime Text over the years. Might give Zed a shot and see how it stacks up.
The other two editors I use a lot are Xcode and Android Studio, and while the first is usually fine, Android Studio (IntelliJ) feels servicable but a touch sluggish in comparison. Given the popularity of JetBrains IDEs I’m a bit surprised that there’s not more demand from customers to make it more responsive.
JetBrains IDEs with their zero-latency typing mode are actually some of the most responsive editors for typing performance: https://pavelfatin.com/typing-with-pleasure/
They can definitely feel a bit sluggish navigating around once you have a giant codebase and you’re using a lot of features, but code editing has been very responsive for me.
Low latency isn't working well on Linux for zer
Agree . Zed has the worst input latency of any app I've used on Linux.
I took Zed for a test drive about a year ago, and absolutely loved how butter smooth it felt to use. It's impossible to describe to others... you must experience it to understand what you're missing.
However, at least at the time, Zed's extension/plugin ecosystem prevented me from making the jump off vscode. Just like it took me a long while to ween myself off JetBrains and their workflow/plugins, it'll take a long while to do the same here - that's if an equivalent plugin exists (yet).
It seems to me, it would be a killer feature for new IDE's to just embrace vscode's extensions and make them "just work". It would remove a lot of the barriers people have with switching IDE's.
Maybe that's an impossible ask... I have no idea, but it would be pretty sweet.
how does it compare to neovim in terms of input lag?
I have not tried neovim, admittedly. Compared to Eclipse, IntelliJ, and now VScode, it's a completely different animal in terms of fluidity and smoothness.
Usually when I've attempted to explain it to others, people counter with things like "but my IDE already feels smooth", etc. I thought so too, until I tried Zed.
My only "complaint" was/is(?) the plugin ecosystem. It's a fairly new editor, so things might change in time.
Which platform? Input and UIlag is worse than vscode In Linux. Vscode is quite smooth for me
I'm on Fedora (kinoite). It was vastly better than vscode - especially when opening and scrolling large files, etc.
What about other Emacs functions such as org-mode? Or did you never use them to begin with?
These were the comments I came looking for. What existing users of Zed migrated from. I'm pretty curious to try it, but lacking some time to tool yak-shave at the moment.
Why was adding AI integration controversial? You go to their website and it seems the AI integration is the whole point.
You go to https://code.visualstudio.com and it will appear that AI integration is the whole point too. How a thing is currently marketed != How people have been using it.
I went from VS Code to Cursor, then got frustrated with Cursor breaking keybindings and other things, tried to go back to VS Code but missed the superior tab completion. Then I gave Zed a long hard try, but after over a month of daily usage I went back to Cursor again, just for the tab completion quality.
I don't use any of the chat or agent features, but for me Cursor's tab completion is a step forward in work efficiency that Zeta and Copilot were not. Sometimes it's subtle, and sometimes it is very obvious. Cursor seems to have sources of context that the others don't, like file names from the directory tree, and maybe even the relevant .pyi type annotations and docs for python modules. It also jumps to the next relevant problem site very effectively. It feels like the Cursor devs have done a ton of practical work that will be hard to match with anything other than a full-on competitive effort.
I want to see Zed succeed. I think it's very important that VS Code and its ultra-funded derivatives not dominate the modern editor landscape too thoroughly. Tab completion used to seem like a straightforward thing, but if the state of the art requires a very elaborate, whole-workspace-as-context environment to operate in, then I wonder if it's going to become a go big or go home kind of feature.
I can't help wonder what the actual internal API for this kind of thing is going to look like in the future. It used to be something like, what's the current token behind the cursor, and look in a big prefix tree of indexed words. Then maybe it got more elaborate with things like tree-sitter, like what's the incomplete parse tree up to this point. Then when editors started using AI, I stopped having any idea of what the actual inputs are. I'd love to hear about real implementation experience at any stage of this evolution.
I think we don’t talk enough about tab completion model quality. Recently Copilot’s model got a lot better (probably trying to catch up to Cursor) but I feel like there’s still so much room here (and I assume Zeds is worse from your description).
Smart context / big context is a really interesting question, I’m kind of surprised Google isn’t building here given how much effort they’ve put into big context (they have Jules and Gemini CLI but no tab completion UX).
On further thought I think one of the big 3 (OpenAI, Google, Anthropic) should partner (ideally not buy) with Zed to get a foothold.
For Copilot the quality of the tab complete is less of an issue for me than the fact that it is often very slow, or doesn't trigger at all when I would expect it to. I'll sit there feeling like an idiot for 10 seconds and then glance at the bottom bar to discover that it's not even doing inference, and have to randomly move the cursor, or delete and retype code until it finally works.
I found Copilot tab completion completion to be VERY slow in Zed, for some reason.
It's fast in neovim.
Maybe they artificially slow down non-official clients somehow? (official neovim plugin, VS Code)
I have the opposite experience, tab completion by Copilot just got significantly worse for me recently (the last week or so), both for Rust and Python code.
I've been working on a better tab completion model that stays as an extension: https://ninetyfive.gg/
The main feature I really care about is low latency, which is my main gripe about Copilot. There's still a ways to go to match Cursor's quality but I'm chipping away at it!
Good work dude! It's way more functional to integrate the overall ecosystem rather than re-forking vscode ad infinitum!
I went slightly differently:
I used Zed for about a year and a half exclusively, without using any AI features, and then switched to cursor to try AI features out. When Zed released its agent mode, I switched back to Zed.
I absolutely agree that Cursor’s tab completion is far superior to Zeds. The difference is night and day. Cursor’s really is that good. But the Zed agent mode works very well for me and Zed is, IMHO just so much better than an editor. I really hate having to use vscode or a vscode-based editor after using Zed so much (I used vscode exclusively before switching to Zed). And that’s enough for me to give up on the superior tab completion.
I hope Zed eventually improve theirs to a similar experience to cursor, but regardless, I love Zed.
nah, I've been using zed exclusively for a couple of months and Zed's agent mode is still worse than Cursor's, but I do agree the quality gap is smaller than on tab completion
I'm in a very similar position, using Cursor just for their Tab model. My ideal choice would be Neovim, but I can't replicate the productivity I have with Cursor Tab.
The tab completion is the only thing that keeps me on Cursor.
I never cared for the LLM sidebar.
But the tab completion is basically mind-reading.
Same. I wish there was an option for enabling just tab completion and disable everything else
You can hide all sidebars in vscode and you don't have to use any AI chat features.
I’m in the exact same situation. Prefer Zed’s snappiness overall but the tab completion in cursor is the only reason I keep coming back.
But at the same time, I’m also doing more vibe coding instead of manual coding as time goes on, so Zed might eventually win out.
What kind of configuration did you use for tab completion? Did you try hooking up different LLMs?
I paid for a subscription to both cursor and zed, without configuring any different LLMs or other options as far as I recall.
This is why I still use VS Code with AI features off and none of the AI integrated IDEs. It's not that I don't use AI. It's just that having the AI de-coupled from editor makes it much easier to separate concerns. Some days I don't feel like using AI and just need to edit one line. Other days I want to do a major sprint and test the latest AI and see if it will accomplish the task.
This is great. I just hope that they continue to make money. We really need someone to invest in making a Fast, modal editor.
Zed is not a great modal editor, modality is a strapped on afterthought. At least that the impression the vim keybinding give me. IMO the best chance I see for a fast modal editor that works out of the box is Helix.
When did you last try Zed? If it was recently then that hasn’t quite matched my experience, for me vim keybindings work quite well. But I did think the same when I first used Zed over a year ago.
I tried it a couple days ago. Lost me right off with the poor `:e` experience; popup box with no completion, fuzzy-matching, sub-directory support. Vim is a file oriented editor, not a project oriented one, so good file operations are table stakes.
I don’t quite get what Zed’s emulation of :e has to do with being a modal editor. It’s a completely different editor so of course the interface to interact with files is going to be different, but in my experience Zed’s implementation of modality when it comes to its Vim mode is extremely good. Even better than the already excellent NeoVintageous for Sublime Text.
Fair point. I guess the problem is with their (Neo)Vim keybindings, not so much with the modal-editing part. I included it as vim is the most popular modal editor and its keybindings are what are lacking.
Are there any modal editors that are not file-based? Maybe it would be better to say this is a problem with its file-based editor emulation?
Is it now possible to import .vimrc, or otherwise configure e.g. the sequence j k to execute Escape?
You can easily configure jk for escape. I don't know about importing .vimrc
Can you explain how?
From the documentation at https://github.com/zed-industries/zed/blob/main/docs/src/vim...
No .vimrc importing, but remapping capability is quite comprehensive.
I at least really like that ctrl-w allows switching between panels as well as editors, something VS code doesn’t do (or at least, you can switch to the explorer but not back?) and is a major papercut IMO
Huh? Zed's vim emulator is one of the best I've used in an IDE. Saying it's an afterthought feels disingenuous. I'm pretty sure some of the core zed devs are big vim enthusiasts.
Does Helix fit that bill for you? It's fast, modal and very little config required.
I think there's also a fork if you can't let go of the VIM bindings.
Helix is a non-starter until it has plugins. Which is taking YEARS longer than it should to get implemented.
The fuck-off-if-you-don't-agree-with-me dictator of the project doesn't help either.
Why? Neovim exists.
I don’t want to install 5-10 plugins with a hundreds of config lines just to make it usable. I prefer zed with 0 extensions and vim motions which are built in.
LazyVim makes it trivial, actually. I would take nvim/vim over VSCode any day.
Not really, it installs even more plugins. Some of them are unnecessary. Ideally, every time you update or install a plugin, it must be reviewed. I just don't wanna deal with it and trust plugin developers.
I already got bitten by an infected Python library (that used to be legit). I treat plugins the same since they can be used in supply chain attacks.
You have to trust VS Code plugins too, along with trusting MS not using your code to improve their AI suggestions, or doing a sudden rug pull. All three happened if I remember correctly.
You can easily enable/disable plugins in LazyVim, and they are simple Lua Script/VIM scripts easy to review. I don't think VSCode would be that easy.
And even with more plugins, nvim/vim will be much more performant then VSCode.
I don't use VS Code, I'm using Zed with zero plugins or jetbrains IDEs with a vim plugin.
When I need to edit something on a server, I'm using Neovim with default config.
I switched to Helix for the same reason. Though I'm thinking of re-trying with one of the lighter weight pre-configured versions. Astronvim seems like the best one after a bit of weekend research.
The one thing I love about VSCode is how trivially I can fire it up on a container or on a remote machine via SSH. If Zed had this I would switch tomorrow.
So my question for Zed users is: does it?
The UI is a tad idiosyncratic on Linux (can't speak for Macs) but DAMN is it fast, I love the generality of tasks.json (haven't played with debug.json yet), by far the best system I've ever used, and everything just works well out the gate.
Zed has SSH editing. But when I tried it a couple of weeks ago, their in-ui git didn't detect a repo in a folder that very much used git, and ports you want mapped have to be specified ahead of time, there's no way to do it at runtime like in neovim/vscode
I've wanted to try Zed but I'm generally antsy about tools unexpectedly phoning home -- haven't had a chance to closely evaluate myself.
A few tinfoil-hat questions: I know obviously it needs to phone someone to use functionality like remote dev or certain integrations, but outside of those situations, does it otherwise perform any kind of telemetry by default? Are there situations where it could ship off tokens in files I'm editing to some remote server where one wouldn't be expecting it? Also, I know it's open source, but is it meaningfully open source in the sense that the prebuilt binaries available for download in the obvious places aren't some reskinned proprietary version like is the case with VSCode?
These are meant in good faith -- genuinely interested and curious
Zed seems really nice, and the usability has come a really long way in the last couple of months. That being said, I have one issue, and I hesitate to even bring it up because it seems so shallow: I hate all the themes! They all look so ugly and amateur. I know this is a really trivial thing, it's like complaining I don't like Python because it uses whitespace for indent or something, but I just can't get over it. VSCode/Cursor is beautiful in comparison.
I recently found Github Dark Default, which is probably the okay-est of the 10-15 I tried, but there is so much that still looks bad. The autocomplete popover looks far worse than VSCode, the file tree looks much worse, tabs look ugly, etc.
Does anyone have any suggestions here?
You're not alone. The only reason I struggle to onboard to Zed is the design. They're doing an incredible job with the editor, but I have never seen a more bland design in any IDE. It's genuinely so bad that it affects my productivity in it. I'm a fan of Visual Studio and VS Code dark themes, I don't need anything special.
Isn't "bland" design precisely what you'd want from an IDE? To help you focus on the code and all that?
It's been a while since I last looked at Zed, so I just started it again, and it ... looks like your average macOS app? Which to me sounds pretty much ideal.
Nothing wrong with bland, but a well-designed IDE does a good job using the UI to allow you to parse information as fast as possible. For instance, compare the autocomplete popover in Zed to VSCode. The VSCode popover:
- Has icons. These are so useful for parsing information quickly!!
- Shows the type information in a different color than the field name. There is spacing between the type name, and the type is smaller.
The Zed autocomplete popover is a solid wall of (almost entirely) monochrome text, all the same size. It is significantly harder to parse. I use the autocomplete popover probably thousands of times a day. These subtle things make a big difference.
Is the Zed popover bland? Yes. Is the VSCode popover flashy? Not really, it's just utilitarian - clearly designed by someone who understood how important every detail is.
I program mostly in Rust, so in theory Zed should be the perfect IDE for me. But I couldn't get past the design. It just put me in the wrong mind space.
As a data point for the Zed folks: JetBrains' RustRover with vim key bindings is still my go-to. It just "looks and feels" right to me.
I'm sure that they'll get there in time. They're playing the slow, careful, methodical game. Writing it in Rust was the right choice and it'll pay dividends.
In 2007 I had the best actionscript IDE that looked awesome and made the whole actionscript development magical. FlashDevelop iirc. It made a huge difference and inspired me every time.
There's a forum thread [0] where users share their custom themes.
There's also an importer tool [1] that lets you convert any VS Code theme to a Zed theme. You might still need to compile the importer yourself, but it's all pretty straightforward.
0: https://github.com/zed-industries/zed/discussions/7337
1: https://zed.dev/blog/user-themes-now-in-preview#using-a-vs-c...
Push through it. You get used to it. Then start to like simplicity of it.
And then, due to speed, there is no going back to the lag infested chromium derivative made by Microsoft.
Believe me, I am trying! I have Zed open and I try frequently to get used to it, but it drives me nuts - the autocomplete in particular.
I agree. I couldn't get over any of the existing themes, they just seem so low contrast... So I spent a bunch of hours porting then favorite theme I've been using in Sublime Text, to Zed, named iPlastic. Sublime Text has a theme back of classic TextMate themes, and it came in that pack. I have to say, the porting process was not very easy, but it was worth it. Now, I prefer Zed to ST and VSCode because of the theme, not just the UI and other features :)
Wish I could just import my ST4 settings and theme into Zed. That'd help a lot. For now I consider it too much hassle and ST4 with LSP is good enough.
I spent a couple hours recreating the theme I was using previously in Sublime Text. The end result was not identical but close enough to feel OK.
I use the Night Owl theme in all my editors (and terminal), including Zed, and the consistency is nice. It looks good, but if there’s a Zed-specific issue I haven’t used Zed in a while.
I feel you. I still haven't found the light theme that would work for me. In VSCode I use Better Selenized. Even tried to import it to Zed but experience was a bit subpar.
I like the Tokyo Night themes, maybe take one of those for a spin
I just made my own. Took about 15 minutes and now it's the best looking app on my Mac.
Yup, this and a few other things. But I expect that Zed is going to be a lovely editor in a few more years.
I really like One Dark Pro, but you have to install it from the additional themes link.
I like Nord Dark because it uses only 3 colours. It’s available as an extension.
Le Blackque is working well for me.
The thing that's so sticky for me with JetBrains IDEs is their run configurations. Being able to configure all of the environment variables etc. for the actual code that I need to run, especially when connecting to a debugger or tests integrated with the IDE.
I haven't seen anyone else complain about this so I figure I must be missing something. Does Zed let you set up run configurations like this? If not, how do users actually run their code? Just in the terminal? It seems backwards to me to use a fancy IDE, but then run all your code in the terminal. I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
Does anyone else have this problem?
> It seems backwards to me to use a fancy IDE, but then run all your code in the terminal.
Having literally spent days at a time just to get a working run configuration at various employers and clients over the past decade, I find it backwards to use anything besides the terminal and version-controlled scripts & task runners / CLIs to fire up anything. (: People rarely document their JetBrains setup fully and even if they do, JetBrains IDEs are not exactly known for their reproducible behavior or for not occasionally messing up your configuration (in case you do decide to check in your IDE config & share with your team).
Besides, you will need those terminal scripts for your CI pipeline, anyway.
That being said,
> I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
I agree, that is very useful. However, to me it's the cherry on top of proper self-contained run scripts for the terminal.
Points taken about benefits of run scripts for portability, reproducibility, CI, etc. I'm mostly just trying to find a way to debug arbitrary programs and run tests in the IDE.
It looks like this should be possible with tasks https://zed.dev/docs/tasks#variables but I haven't put enough time into figuring it out yet.
Maybe my use case is too specific, but I'll spell it out just in case: I try and open a Django project in Zed. I go to a test file. There's a > arrow next to the test to run or debug, but it will only run it with PyTest (I use unittest, but PyTest is backwards compatible, so w/e). When I try to run it, it fails because some environment variables I need are not set. I don't see how to configure them so I'm dead in the water.
I'd also love to run the Django server with a debugger attached. It's not clear to me how to do that. I haven't found the rights docs. Dead in the water again.
Maybe I need to spend more time exploring and reading the docs :)
Same here. Zeds task configurations are not nearly as versatile, easy to set up and run as pycharms especially when it comes to virtual envs. The debugger is superior in Pycharm too. But in terms of overall use Zed is good.
My other complaint is that pyright (used by Zed) isn’t nearly as good as pycharms type inspection.
I love these too. I have a run config checked into my repo that runs three run configs, for `fastapi dev`, npm start, and launching a JavaScript debugger, with one click. I also like clicking on a test or script and just hitting "ctrl+shift+d" to launch that particular code with the debugger.
VS Code can launch a fleet of dev containers but it's just not as good of an experience to restart and debug.
For personal projects I just use npm scripts or make
Minus some magic, those scripts are not going to interface with the IDE debugger.
What I'd really like is an option to disable the automatic multi-buffer behavior for things like git diffs. It just doesn't work for me, and the Zed UX seems to not even realize that not everyone will love it.
The multi buffer is the most amazing thing about Zed. AI be damned. It now feels wrong to use an editor that doesn't have it. It is so obvious in hindsight.
Honestly, this is a weak point of Zed IMO. I just find it a bit confusing to deal with. I don't know exactly how to get it to jump to the location of a specific block in the multi-buffer view, e.g. a Find in Files view. I double click various places in the UI until it goes to the file and sometimes I have to scroll to where I was at in the multi-buffer view. It's very frustrating.
I think it could be made to work better, but as it is now, it feels cumbersome to work with.
I believe what you want to do is click on the line numbers, which should take you to that exact point in the file.
Could it really be that simple?!
Holy shit. It really is that simple.
Thank you.
you can also use alt+enter while the cursor is inside of a multi-buffer, and it will open at that point in the file.
Even after figuring this out for myself I still struggle to do it fluently.
There's a setting that will allow you to double-click to open a file from the multibuffer which I find more natural:
Took me a bit to find this, but you can click on a line number in multi-buffer to open that file at that location. I think their default assumption is for you to not use the mouse much. If you're using vim mode g+[space] will open the file where your cursor is. I think it's alt+return in normal mode but either way there's a shortcut hint on the right side of the header for the file your cursor is currently in.
It also tell you that "alt-enter to jump to the file" in the "header".
I think this is one of the best innovations in Zed, though it could use some more polish to work really great. Being able to edit the diff directly surely is a great thing?
The problem is that it insists on jamming together all files in the list, each with only a tiny bit of context, when I want to look at things one at a time with full context, and there's no way to change that behavior.
"Alt-Enter" jumps directly to the selected entry in the git side panel. Ctrl-clicking works as well (granted it's not obvious)
I find it more effective (for me) to keep my AI tools separate from VS code. It helps me control when I actually apply AI
Sadly, I came back to using VS Code recently. There's a lot to like in Zed but imo that decision to write their own rendering framework is unfortunate, because of ridiculous problems in Linux still not resolved like poor font rendering, especially on low-DPI screens, or visible lags of UI which is being developed to be blazingly fast. So far, VS Code is faster for me.
Remember that Zed hasn't reached 1.0. On other platform, it is much faster and consume much less battery. Just like ghostty, to me the most attracting feature is knowing my editor/term is not backed by a browser engine.
> the most attracting feature is knowing my editor/term is not backed by a browser engine
How and why is this important? At any time I have two browsers with dozens of tabs and on top of it a slack client active, how another instance of a browser engine could hurt in this mad world?
try it and found out; it's not about memory overhead (maybe it is to someone), it's that it works so much better than web backed things. it's just an absurdly fast/responsive/delightful thing to experience after years of everything going the other way [while hardware actually gets faster]
and i say this as a proud career long web developer. i just really like zed.
Zed was my daily driver for almost a year. When it's working fine and not drawing the mouse cursor at 3 FPS it feels pretty much as anything else in terms of perceived speed. I saw mentions that you need to be younger to notice the difference. Like you don't hear frequencies above 18 KHz if you're more than 20 years old. I get the idea, I just don't see where it is connected to my real world experience
As a quick anecdatum, I'm on macos and I'm definitely more than 20 years old, and there is a quite perceptible difference in responsiveness between Zed and a VSCode-based IDE for me. (Though then again I did play fast-twitched games a lot when I was younger.)
Ghostty is an apt comparison, because it is a slow-launching memory hog compared to foot on Linux.
I listened to a podcast interview with one of the cofounders of zed. One of the revealing things is that he went on and on about how important latency was and how they had to do their own rendering because of the problems they ran into with electron. He also admits that he never used vim, which already has imperceptible latency relative to the terminal emulator, which has already largely solved the text rendering problem.
I understand that there are advantages to being a native app from their perspective, but for me, it is even better for my editor to be integrated into my terminal editor. And because they built it the opposite way though, they have to also build a terminal emulator into their editor.
There is a real cost to building zed this way. If they were an embedded terminal app, they would get full terminal support for free and would not have to implement 2d text rendering. They could even have made a bundled package with an oss terminal emulator like kitty. Then they could have focused strictly on their editing features and value adds. Every engineer hour spent fixing bugs/adding features to the rendering framework is an hour that could have been spent on value adds.
Personally, there is no way that latency itself can be that value add for me because I use neovim and don't use any language plugins so every keystroke already renders instantly. Clearly then you can do everything zed does in a terminal app within at worst tens of milliseconds of latency.
Of course their target market uses vscode and not vim and either doesn't know or care that you do not need to write your own rendering engine to make a low latency, featureful text editor. I am admittedly very much not the target consumer for zed though.
Not everyone wants to use a terminal editor and of those people, not everyone wants to use vscode.
Learning a terminal editor will save your ass at 3am when production goes down. No joke.
Learning a client-server editor will save your nerves when developing on a remote machine with 200ms ping
Vim and emacs both also support editing remote files.
"Support editing remote files" and "work with all plugins on remote that feels like editing on local machine" are different things
learning both is fun!
Learning and wanting to use as a daily driver are very different things.
I use vim on my servers and for writing git commit messages. For everything else, I use another editor (used to be Sublime Text, then Vs code, now Zed).
Nailed it. I'm fine with using vim to do remote work. I'm not an expert, but I have enough muscle memory to zip through the things I need to do. I don't want to use it exclusively, though. Turns out I'm capable of learning my way around multiple tools and using different ones in different contexts. Who knew?
I don’t say I don’t know how to use one. I was a longtime vim and then neovim user. But I don’t want to use one.
I still use vim for quick terminal edits, git commit messages, and doing stuff over ssh. But for my day to day heavy text editing, I do not want to sit in a terminal and be limited by what a terminal can display.
Thats why nano exists.
At 3am i am not in the mood trying to remember where my 714 page how to save a file and exit vim manial is
I seem to hear this a lot, but there's probably like 10 commands (maybe a few more if you want to be fancy with copy-paste). Note: great if you like nano however!
For those that are interested, this will get you 90% there:
exit without saving> :q!
exit with saving> :wq
beginning of line> 0
end of line and edit (enter insert mode)> shift-a
delete line> dd
insert mode> i
stop insert mode> ESC
undo> u
show line numbers> :set number
go to line number (e.g line 5)> :5
It is easier to remember one command: `nano <file>`
+1, nano even gives you a handy hint bar at the bottom in case you forget any of its' shortcuts
Why does a text editor of all things need faster rendering, I have never seen this to be an issue
Why do yaks need to be shaved?
+1 I've explored Atom when it was the hot thing, and more recently, an IDE called Lapce, which is built in Rust and doesn't use Electron. They've been great, but the lack of an ecosystem stares glaringly right at your face. I don't like Electron apps but VSCode gets the job done.
I have my entire set of plugins and things installed here and now the productivity that I get off this setup even exceeded my long-loved Jetbrains IDEs. I hope that will be temporary though, seriously. The only thing that I strictly dislike about VSCode is the number of high quality themes available - and there are not that many.
Recently stumbled upon VSCodium which is a clean VSCode fork that can work with any VSCode plugin, but I am yet to try it out.
I miss Atom. I loved it. I loved all the crazy plugins people would make to do all sorts of things. It was a fun time.
These days I'm stuck on QTCreator most of the time. It's OK for core editing functionality but there's a lot that I miss, and some things like the generic Language Server support just aren't fleshed out much.
I'm tempted to use another editor whenever I'm not working on UI files but it adds some friction.
Was atom functionally ever any different from vscode today?
I only remember Atom being painfully slow. It was using Electron too btw.
At the time it was actually called "atom shell" iirc. Electron came from Atom.
> VSCode fork that can work with any VSCode plugin
Technically yes, but if you care about legally, you can't use extensions from Microsoft's marketplace, which excludes Microsoft's own closed extensions such as WSL/SSH/devcontainer remoting and Pylance. It ships with Open VSX instead.
Doing their own rendering is one of the most attractive things about it imo. I am on macos though.
Even on a mac the text rendering is wonky though, like it isn’t processing the metrics correctly or something.
At least it is noticeably fast.
Text rendering is awful on macOS too. I can’t even consider switching from Sublime Text because of it.
Wondering if you've tried rxi/lite or the community fork, Lite-XL [1] and how you've found the font rendering to be there?
FWIW, I've yet to find a better text editor than Sublime Text.
[1] https://github.com/lite-xl/lite-xl
Yes, I've tried them (Pragtical actually, which is another fork) and font rendering there is fine
I use it on Linux and think it's great. My laptop has a screen with some crazy-high DPI and a monitor which doesn't. Changing the font sizes in settings to suit has never left me with a poorly rendered view.
Same experience here on Linux, where bast majority of potential users seems to be in Linux who loves vim mode, Zed's focus on Linux is pretty bad. I would say alpha quality at this point.
VS Code also lags and become buggy if there are incompatible drivers and it cannot enable hardware acceleration.
Zed's still pretty beta on linux.
It will improve. I'm glad they are at least targeting it as well.
I appreciate this option since I use Zed without AI. However, their overwhelming focus on cramming AI in the editor just disappoints me. The core experience is still very raw and there are small things that build over to make it annoying.
I still have Sublime Text as the backup editor. It's lack of a powerful sidebar and search are the only things that stopped me from using it regularly.
I do use VSCode at times and the CoPilor powered tab completion (which mostly hallucinates and spits out nonsense) is just obnoxious. I've found JetBrains' implementation of full line completion and block completions a lot more thoughtful and reliable.
Just wanted to say thank you to the Zed team for listening to this bit of feedback! I'm very much of the opinion that AI is not a value-add, so I appreciate the ability to disable it.
It should be like it should be with JavaScript: it should work without it by default.
But the reality is like for JavaScript: it's required by default :D.
Good that Zed fixes this!
Something tells me that disabling AI is going to age about as well as disabling JavaScript. Even so, I like what Zed is doing here.
Disagree. The tab completion is very annoying when you’re trying to type. I know, I know, AI hipsters think typing code is so 15 minutes ago. Get off my lawn/keyboard.
Its agent AI assistant isn’t bad but sadly the restore points button in the AI panel seemed to be broken.
The fact it reminds me of sublime text is a big plus for me.
The rust evangelism is annoying. Really. No one cares what language a program is written it.
> The tab completion is very annoying when you’re trying to type.
I think it is annoying if it completes it by itself, but tab completion can be helpful if you have to push the tab key (or whatever other key is mapped to autocompletion) to make the completion to work (although I don't need LLM to do tab completion).
Do you not use the tab key to indent code?
I don't indent with tabs, but I also don't usually use autocompletion in the text editor. I usually use tab completion in the command shell.
In most code editors, hitting tab increases the indent even if you are using spaces (e.g. it will add two or four spaces). But now you don’t know if it will increase indent or arbitrarily rewrite your code.
Yes, which is why you could use a different key or key combination for auto complete.
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. In cursor, it’s at least 80% of the time jumping to the next thing I was going to do anyways. (Example: I add a function call, and tab recommend jumping to the top of the file, importing the function from the right spot, and then jumping back to the call site. Example2: I change a function signature and update one call site. It then correctly auto-completes the 5 other call sites to match the new format.)
both of those examples (auto imports + refactoring) 'just work' in Jetbrains editors, and have for a decade, without any AI at all! and you have the added benefit of no hallucinations when doing a refactor across hundreds of KLOC
Also even if you want AI, the AI is a lot more powerful if it can use those features instead of constantly getting stuck on wrong imports.
Disabling JS is incredibly beneficial for browser performance, battery life, privacy/tracking protection. As an added bonus, it protects you from malware from all the vulnerabilities in Javascript engines.
Which vulnerabilities in the past few years were actually used as a way to propagate malware (Not targeted 0-days)? Even with a JS engine vulnerability, you'd still need a sandbox escape to do something useful with it
Most of the vulnerabilities I've seen that could infect your machine from a website require JS to work and most of those had nothing to do with the engine itself. Sandbox escapes are extremely common. Chrome patched one that'd been being actively exploited just last week
It also makes a lot of basic features on websites unusable. Just an HN vote uses JS. They deliberately added a fallback to work without it too, which most websites won't do, but it still has to reload the page.
Because of my job I end up browsing the web with JS disabled by default and 90% of the time I don't need JS at all. Most of the time there are features of websites that break/don't work (menus, search, videos, ads, etc) but the actual thing I went to the website to get works just fine. In fact, pages load much faster and look much cleaner!
There are some annoying websites that can't manage to display simple text or even a basic image without JS (which is just bad web designers doing bad web design) and some instances where the content I need is obscured by something that doesn't behave without JS (like an expanding menu spewed out all over the place because JS isn't there to hide what hasn't been selected/hovered over) but in those cases it's usually just 2 clicks to solve the issue (either for just that visit or for every visit to that domain in the future as well) so it's not really a big deal. I'm currently using HN without JS and it's great.
If you just want to read text, that makes sense. And HN will also fully work without JS.
Do Zed AI features require interacting with third-party providers such as OpenAI? If so, I don’t think your comparison applies.
I use Golang from JetBrains, and disabling all AI features is only two clicks away. No fuss no muss.
A friend of mine created some business plans to help organizations migrate from cloud infrastructures back to on-prem solutions. Like AI features, the sweet spot is somewhere in the middle: hybrid has its place instead of cloud-only, and AI features have their place instead of "everywhere."
This is great, My 2 cents since I see a Boolean:
what if that setting were an enum every operator started with AiMode::Off so we can consciously opt-in, plus then Zed could have more AI Mode levels besides just on or off?
Maybe there could be a level for experienced programmers and another level for vibe coders, and prompts / permissions could be set accordingly?
That's basically the case when you have AI mode on in Zed today.
The four AI features in Zed (that I'm aware of) are:
* autocomplete -- this can be turned on and off separately from the AI features toggle, and can be put into 'subtle' mode, where you have to hold a key to see the completions.
* inline AI editing -- only activated by hitting ctrl-enter, otherwise you'll never see it.
* agent/chat editing -- you can disable the right-side chat panel, and you'll never see/use this.
* AI generated commit messages -- there's a button you hit in the commit message panel to activate this.
Zed has been moving fast lately and I can almost use it full time, but no git log and poor git diffing has me frequently clicking out of it. They are spending a huge amount of dev time on AI features instead, so this is a nice feature, but it still doesn't change their focus.
Zed is the best editor until someone finally adds a perfect agentic mode for Emacs so I can go back 100%
I used Zed a decent amount before it started being too in-your-face with AI features. Glad to see an option to disable it all, but at this point, I’ve become so much more efficient with Helix than I am with any graphical IDE. I wouldn’t love to go back.
I did 4 months of Cursor. Figured I’d try 4 months of Zed, and see from there. I’m about 3 months in and so far might stick with it. I’ve generally been pleased with it. My only issues really have been
a) all the settings are just in a file, not even a commented skeleton, and with a decent change rate, hard to invest in learning them; I’d love something like the jetbrains settings dialog
b) the stupid placement of the burn mode button; it’s so easy to accidentally turn this on and not realize (done it twice now). Would love an option to just remove said button
c) I wish there was more panel control; I’d like to place outline and project views BOTH in a panel, but you only get two full height tools in the left/right panels.
Also wish they would put more emphasis on autocompletions, that's like 99% of what I use AI for is basically a better Intellisense
Other than zed.dev being down for the first time since I started using it, I’ve been manually disallowing AI connections from the get-go. What’s different? What wasn’t I disabling originally? Is this just a shortcut to other options?
"Some developers have fundamental objections to AI in their coding process—whether it's concerns about training data, environmental impact, or philosophical reasons about machine-generated code."
not only that, there's the "jesus christ fuck off" angle. Stop bullying me into using AI when it serves you, not me. Every goddamn surface wants me to click on their "write your email like a fake idiot" button because they get to report X% WAU uptick which is supposed to vaguely correlate with revenue/growth somehow according to some stupid metric. But no matter how much you can twist reality to justify it financially the fact remains that shoving features in your users' face is not the best user experience you could have made, because you could have not done it. Good designers (...picture your platonic ideal of Jobs-era Apple, not that it was actually perfect but it was better than this shit...) would never do that. If only we lived in a world where there was enough market pressure to annihilate a company for designing things badly---unfortunately no one is competing on that angle yet (big opportunity, imo). In the meantime we just have to ask, nicely and then angrily: please, god, fuck off. It should not take angrily asking, or finding leverage, in order to get you to be respectful. You should be respectful by default.
Weird that it wasn't optional before, right? Not sure if this is related to the recent stories of AI agents nuking people's code, but that's just one more reason to make it optional.
My problem with AI in Zed is not that it's there, but that it feels like it's always behind in AI code editor paradigms. They were pretty late to the party to add edit predictions, and their agent UX is pretty behind the game. Recently, Cursor added background agents which I feel is a game changer and I now feel it's a deal breaker when choosing an editor. It makes me wonder if choosing to build their own GUI framework in Rust was the right move. Zed is a great code editor, but for me, it's not a great AI code editor.
I haven't used background tasks/agents in cursor. Could you provide an example for stuff that you use it for?
This week, I remember giving it these tasks:
- Upgrade our NodeJS version because it just got deprecated
- Upgrade our linter to the newest version, add a new rule, and fix all instances of that rule in our code
- Make minor changes to our UI
- Fix small bugs that I know how to fix, and can tell it exactly what to do
The main pain point they're solving for me is that I have many small tasks I need to do. Coding them isn't the main bottleneck, but creating a new branch and then creating a new PR is the main bottleneck for me. With cursor specifically, I don't even have to check out the branch locally to verify the code.
For any significant work, I'd rather manually do it in editor.
Maybe this is a pedantic nitpick, but I do wish the feature was "disable_llm" or similar.
The term AI is so poorly specified today, and while I don't want my editor using LLMs to predict my next keystroke I do still like the more basic auto complete features.
I think I'm never going to get another software job because I cannot stand the word "agentic".
Of course the software industry will probably make any desire I might have a moot point anyway.
For what it’s worth, I would really like to have an iPad version of Zed that I could use the remote function into my Mac and homeserver via Tailscale and be able to code on my iPad.
Please make this!
I want this in Warp. It's a solid terminal, but Claude Code is so good that I don't need my terminal trying to do something similar without me asking it to.
If you want this for Warp, you know where to find xterm, iTerm2, Kitty, etc.
Have you tried foot?
I loved foot but now I gotta use a macbook :(
Total nitpick, but:
Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true?
Are there some mechanical semantics I'm missing here that make this beneficial?
Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.
Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.
Enable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?
First of all, enable/disable is a dichotomy, and is not a set of two dichotomies.
Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.
In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.
Imagine for example you're in a court of law. Which one sounds more damning?
======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?
Defendent: But Enable_AI just means enabling the use of the output! ====
==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?
Defendent: Uh.... ====
> Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.
Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.
Well, I do feel a distinct connotational difference, but then again, I could be the only one I suppose. And if the average person doesn't care, then why argue about it at all? And how many average people will be using Zed anyway?
> why argue about it at all
Because double negatives are confusing. Enable_AI = true is much clearer than Disable_AI = false.
I don't buy your argument.
> ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?
Defendent: But Disable_AI just means disabling the use of the output
Well, I guess we'll see then. Or not.
======= Prosecutor: You still have AI tasks running in the background but AI_Disable is set to true?
Defendent: But Disable_AI just means disabling the use of the output! ====
==== Prosecutor: You still have AI tasks running in the background, but AI_Enable is FALSE?
Defendent: Uh.... ====
...it cuts both ways, sorry.
Perhaps. I could be the only one that senses a difference, but for those that hate AI like I do, "disable" sounds better than "enable".
My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)
If it was just CGO=true or CGO=false I think so much confusion could have been avoided.
I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.
> It's set to 0 or 1 to enable/disable (can never remember which mapa to which)
That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.
I've no issues with boolean logic (&&, ||) but unfortunately all my schooling has done those with the notion of true/false instead of bits iirc.
This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies.
This is not unique to Go.
I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?
I don't think me writing an if condition
if boolean != true
instead of
if boolean == false
should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.
Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.
Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.
I always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_DISABLED, MOCK_ENABLED, etc.). I thought env vars are always considered optional by convention.
At least in the case of cgo_enabled it does define the default behaviour
It makes sense, historically.
They had AI features that were always on.
Some people complained so they introduced a flag to, wait for it, disable the ai features.
So they didn't think too deeply about it and named the flag "disable_ai" because it mapped into how they were thinking about it.
You overstate the problem with negative booleans. It's trivial for them to add a function:
and just use that.I mean you may equally want
if(disable_ai) { //disable shit }
They are trying to communicate that disabling AI is a product feature to some customers.
I think it's reasonable to, for example, have a field that is labeled "Do Not Track".
The wording implies that disabling a default feature is used by a handful of edge cases and Zed has done their best to accommodate these users.
From a business perspective, investors want to hear that AI is indeed part of the shipped product.
It's all about optics.
"disable_user_tracking: false" vs "enable_user_tracking: true"
"disable_adverts: false" vs "enable_adverts: true"
Fewer people would actively _enable_ user tracking or adverts compared to those who would take extra steps to _disable_ them.
I concur. Same thing in many UI frameworks where you’ll have a Boolean “isHidden” to control visibility. Makes it so hard to reason about.
IMHO, in this case it should not even be a boolean but an enum {Visible, Hidden}.
Even with working with an existing framework, we can define a constant `HIDDEN=true`
IMHO flags like this should always reflect the planned steady state. If you plan for a feature to be on in general, then the flag should be a disabling flag that eventually goes away.
It's good and predictable that all boolean settings to be false by default (when not set). And the default behavior is the one that is compatible with older version — changing the defaults is a breaking change that should usually be avoided.
Yes, this is especially useful if the boolean settings are stored in a bit field, in my opinion. In the case of Zed, according to the article, it uses JSON, but if a program uses a bit field instead then it would make sense.
I think AI-enabled is going to be the default for all future code development. Autocomplete is just so good, and I never want to go back.
I spent 20 years without it. That's enough for one lifetime.
How long did it take for you to get used to the autocomplete?
I completely hated it when I tried it out. It breaks my flow. Those weird pauses are so painful. Feels like someone grabbing the steering wheel while I am driving.
I heavily use the agent mode but I don't understand the appeal of the autocomplete feature but maybe I am missing something.
You spent 20 years without autocomplete? I started using Eclipse's autocomplete & shortcut macros in 2002.
It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.
That's not at all the same.
AI autocomplete can generate the entire `match` tree for a very complex Rust enum, and also generate all of the associated tests. It then takes me to the next places in the code where changes need to be made. It's wildly good at knowing exactly what I want to do next.
2002 macros and autocomplete were not that and cannot possibly be compared in the same light.
{ "disable_ai": true }
That creates a system with a potential double negative (disable is false) which is unclear.
It's cleaner to do:
{ "enable_ai": false }
Zed has everything I want out of an editor, the AI stuff wasn't really a concern to me since its always been optional, but I fully appreciate where they're coming from. I think Zed is one of the good gems of our time. I have been looking for a decent spiritual successor to Sublime, and Zed to me is really good at it.
I moved to Zed last week and its been amazing so far! Something about using it feels a lot more crisp and fast compared to vscode. Their AI integration is pretty decent too. But I am very glad I can disable AI now. I find AI sometimes takes me out of the flow because I am constantly reviewing its code.
Meanwhile (at least from what I've heard from friends), VS Code is pushing for users to use Copilot more and more. I'm glad I jumped to Zed a few months back.
I'm glad they decided to add this. I still want the ability to disable all the account login stuff part of the UI. So i hope they make that as an option too. Since, I don't like signing into my software.
Why is a code editor negging me?
"Even if you're skeptical [of genAI], these tools are quickly becoming part of how software gets built."
Yeah, well, you know, that's just, like, your opinion, man.
I am thankful Zed added this feature and most of the post seems reasonable, but it's still the height of weird that they feel compelled to say this—obviously it's not how software gets built by the people who are avoiding these tools intentionally and for good reason!
Especially given the recent study that found people felt more productive while objectively getting less done.
It's like saying, "marijuana is rapidly becoming a part of how people get through their day, but we understand not everyone wants to spend their day high."
Zed has been nice, but I really miss the fuzzy search (files and grep) with live preview - something like telescope in neovim. The search results in zed feel super clunky to navigate through.
FINALLY was waiting for this. This is a great feature it was annoying af.
This gives me hope they might fix collaboration too. Unfortunately had to switch to VSCode Liveshare (which has its own problems) a few times because Zeds collaboration was so broken.
Love this. Prefer deciding feature by feature basis, but in a world where everyone is ramming AI down your throat with a jackhammer and compulsory ToS this mindset is welcome
I am really, really starting to like Zed. I noticed recently that it now respects my EditorConfig files, which was one of my biggest gripes before recently. In general almost everything that I didn't love about Zed has been fixed.
I have only tried it a couple of times, but Zed's AI assistant view indeed works as promised, doing about as well as Cursor does.
Now there's just one thing that is a bit annoying... It's kind of heavy on the GPU. I mean it looks and runs great, but it really loves to suck the battery out of a device that's running on battery. But frankly, I've been ready to ditch text editors based on web browsers basically since they became "in vogue" and have just been waiting for the right thing to show up. As time goes on, I think it becomes more and more obvious that Zed is "the right thing".
I don't know if there's anything we can do to make sure Zed succeeds sustainably and doesn't eventually get enshittified, but I'm crossing my fingers that for once we can have nice things.
Re GPU usage: noticed this myself a few months back and decided to poke around. Recommend turning off the minimap if you have it enabled. There seems to be some over-rendering that is exacerbated by it. It's actively being investigated and improved upon (0.192 was a great step in the right direction) but, even still, I've found it (currently) has a big positive impact once disabled.
It hasn't been a huge deal: I'm still getting a decent number of hours doing work on battery on my Framework 16, and usually I can plug into AC for a little bit if it gets too low. That said thanks for the information; I'll have to keep it in mind.
> I don't know if there's anything we can do to make sure Zed succeeds sustainably and doesn't eventually get enshittified, but I'm crossing my fingers that for once we can have nice things.
This is a good conversation to have. We can start by pointing this out and encouraging broader interest. Zed has been my daily driver for over a year.
I'll make a claim -- does anyone disagree (?) -- the incentives are not pointed in the right direction. Unless developers are paying directly for the functionality they want, that's misalignment. So enshittification seems probable, maybe inevitable, unless something structural changes.
OTOH, because they charge for their editor, JetBrains has incentives that are better in line with customers.
> I'll make a claim -- does anyone disagree (?) -- the incentives are not pointed in the right direction. Unless developers are paying directly for the functionality they want, that's misalignment. So enshittification seems probable, maybe inevitable, unless something structural changes.
Exactly.
AI autocomplete I just don't care about. OK, but they do offer an AI subscription service. I'm using LLMs almost not at all currently, but at least right now this does seem like a viable path to getting a lot of money. I worry, though, that in the long run, the margins will just get squeezed by competition here, especially when a lot of deep-pocketed competitors can charge nearly nothing and get away with it. Zed also very nicely offers the ability to drop in an API key for their AI agent features... which is awesome and the right thing to do, but not good for profitability.
Obviously, the issue with simply charging money like Jetbrains is that Jetbrains already has built a world where they have a super complete IDE package and even then they only really charge a relatively small amount per month for the privilege. It works because for software the development costs for a given piece of software is relatively "fixed" (not entirely, but close enough) whereas the revenue you get grows as you acquire users. But now that the market is saturated, it's going to be hard for someone to jump in and try to be like Jetbrains in any way, and if you're charging money it's even harder to compete with most of the other code editors that are ~free.
Worse, it's hard to charge money and remain completely open source. Linux users will mostly not even realize you're doing it because the packages will just keep working for free since the software is open source. And Zed really does benefit from being open source, maybe more than many other open source offerings; it really seems like the community did a lot of work on making Zed work well on Linux. (By the way, if any of you who worked on the Wayland support for GPUI happens to read this, thank you very much for the excellent work.) So it's hard to say "just go closed source!"
I hope Zed Industries got a good deal on whatever funding they received and are being somewhat conservative with their funding too. Even though it's hard to compete in this market, they've built something that is very hard to build and basically not paralleled as far as I'm concerned. There's clearly something here and finding a less shitty path to monetizing it would be very, very good for us all.
(And I am willing to pay, though I know they need to find something that will make a lot of people want to pay, not just people like me.)
Maybe a year ago (or couple of months ago, I can’t recall) but I found out about Zed and since I was learning Rust, I wanted to contribute. But then I saw that they have a CLA. So while it won’t be easy to go closed source and not upset their users, it definitely is possible. Any contributions, no matter how important, are already covered by the CLA.
I did not contribute anymore after seeing the CLA
Ah yeah, they have a CLA that forces you to give them a carte blanche copyright license to contributions and they also restrict dependencies to be ones with permissive licensing too.
Pretty obvious what's going on here. I hate seeing it happen, though.
FWIW, we plan to sell "enterprise" builds of Zed with SSO, centralized plugin repositories, business-hosted infra, etc. etc. The sorts of features developers don't care about but businesses do. To do that, we have to be able to re-license the codebase and apply these changes. We have a lot of other ideas for business sustainability but the core, offline code editing experience will always be freely available and open source though :)
I don't really expect you to respond but if this is true why not use a CLA that guarantees the code stays open source? The FSFE FLA exists and is prominently used (though optional) by KDE.
Hey - I'm the founder of WorkOS. Happy to chat about the playbook we see with OSS projects spinning-off a commercial offering. It's pretty common and we work with a lot of these businesses, enabling them to continue investment in the ecosystem too. mg@workos.com
Damn where is the "stochastic interwoven unpredictable" graphic of how they can use a webpage to pin my firefox to 100%cpu and start blasting fans
What an amazing selling point!
It requires lots of independent thinking (which I value) from founders to refrain from something everyone else is hitting the gas pedal on.
refrain? they're going full steam on it. they're just not forcing all their users into it, which reflects taste and empathy few other founders have.
Taste and empathy maybe, but their choice of licenses, technologies and priorities can still be juvenile to the point of sinking their company.
Just look at the amount of excitement in their industry right now. New IDEs are springing up practically by the week. Are any of these new IDEs based on Zed?
No, of course not. GPL closes the door on that, and who would want to own a fork of a tool that's so painful to develop? Developers working on VSCode can probably do an average dev-test cycle in 1-5 seconds. I've no idea how long the Zed dev-test cycle is, but I hear Rust builds are notoriously slow so I assume it's more like 1-5 minutes.
With the help of subsecond[0], we're seeing <1 s dev-test cycles for changes to Rust GUI projects these days :) That's with a fast CPU and optimized compiler settings, but it's competitive with things like Flutter and the web stack.
Even without hotpatching, Rust incremental compile times are on the order of 10 seconds, not multiple minutes. Clean compiles still take minutes, but that's a "once-a-week" workflow usually.
Not sure if Zed has gotten it hooked up yet, but things are changing rapidly in the Rust GUI (and games) space because of Dioxus's innovation here.
[0]: https://crates.io/crates/subsecond
Thank you for educating me. I don't actually work with Rust so I shouldn't be spreading misinformation about it without knowing what I am talking about.
It doesn't really change my multitude of problems with Rust as a language for a project like Zed. Zed feels like a cathedral to me in the Eric S Raymond sense. Rust feels like a language for building cathedrals. Javascript is the language of the commons, which is why the idea of a hackable IDE in JS was so brilliant. Somewhere along the line the team forgot what made Atom great (despite its flaws).
Do you know what I like more than AI in my IDE (which I adore, by the way)? It's an IDE that respects the developer.
Yep, fwiw there's often live coding interviews done in the editor of your choice that require AI to be off.
As in even if you love AI and use it a lot you should have the ability to turn it off.
The ones I’ve done (as of late last year), they were okay with AI autocomplete but not a full prompting/agentic workflow.
They wanted me to architect the solution, but were okay with it filling in basic for loops.
I would actually start interviewing with AI as well. How well they prompt and how good they are at reviewing AI slop?
Yeup, this exactly. If they're going to be allowed to use claude-code/copilot day to day, how well they review the ai-generated code is going to be huge signal, as well as they could explain what happened. Also, if they're jsut blind vibe-coding something, without creating a nice quick spec for the LLM, that would also be a signal. Also, makes for very easy follow on questions during the interview.
Aw shucks, I guess that rules out Notepad on Win11 then.
> It's an IDE that respects the developer
Mind elaborating?
I assumed they meant having the option to turn AI off was them respecting the developer.
Which is why I still code and write with Sublime Text!
i use nvim and arch btw
I hand write all my code directly in binary.
I do that too, and then execute it by hand as well, looking up every instruction on paper and changing the registers on paper as needed.
> i use nvim and arch btw
^ Has C# projects on github. Don't think that statement is true.
I use vim, kitty, and arch btw
> ^ Has C# projects on github. Don't think that statement is true.
Why?
I fucking love Sublime!
Yeah! Fast, good looking, no AI integration, ability to turn off blinking cursor and customize, and paying for it supports a small company in Australia rather than a huge, soulless megacorp.
> Our goal at Zed has always been to build the world’s best code editor.
Not true, Zed goal is
> code editor [with] high-performance collaboration with humans and AI
> code editor [with] high-performance collaboration with humans and AI
When investors are involved this immediately changes to:
> Our goal is to build a product which will hopefully return more than our financial investment.
I get the feeling many HN contributors to this discussion forget that Zed is not a software project like Neovim, Nano or Emacs (etc.) which rely on donations and/or sponsors to either pay developers or cover required infrastructure costs.
It's a product backed by investors who - one day - will demand their pound of flesh, and "features" like AI are added to market the product to _more_ investors.
Perhaps the use of AI itself inside the product will also be tracked to steer potential opportunities for the investors themselves.
Like many fellow HN'ers, I use Zed on a daily basis, and it's no different than Google search or Facebook - "If a product from investors is free, YOU are the product"
I've tried Zed last week but C# LSP (Ominsharp) had too many issues. Does anyone use Zed with C# with good success?
I've been using Zed for half a year. Love the simple interface. I wanted a glorified notepad. Zed does well for me.
Has anyone got Zed to work consistently on Ubuntu, specifically with nvidia optimus laptops?
good one. Just yesterday It got me to a point that I can't stand ai forced auto completions in vscode that I ended up whole copilot extension. It's too distracting that Ms forcing too much on AI
I tried Zed many times. In fact I try to use it at least once a month because it is indeed fast. However, I just think it’s a half-baked product and I don’t want to invest too much time into it. Wish they didn’t get distracted by AI and focused on making a viable VSCode replacement as an IDE/Editor.
What do you think is half baked about it? I've found the experience quite good myself.
I mean all good but I still wonder if building an editor is really sustainable you basically only fight for new coders everybody else will just stay with vs or IntelliJ because of muscle memory
I know you can share keymaps but it never works 100%
Like I must’ve been tremendously more disappointed with my current ide to even consider switching
Counterexample: I went Sublime Text 2 -> ST3 -> Atom -> VSCode -> Zed, and every time barely noticed a difference in editing experience. The keymaps were >95% compatible after each of these switches. But I guess that was the happy path given these editors share lineage.
OTOH I was never able to switch to Jetbrains IDEs for long, because everything was too different, even after installing compat keymaps.
> Even if you're skeptical, these tools are quickly becoming part of how software gets built. Understanding them helps you make informed decisions about when and how to use them—or not use them.
What? Blockchains and Web3 again? Oh no wait... AI
What is the point of this? Surely anyone who (correctly) has moral objections would require a fork getting rid of the code to support it entirely, not just a runtime toggle?
There are more reasons than moral objections one might not want to use the AI features in Zed. The post gives a few concrete examples but I think this sums up the general situation best:
> Zed is built for engineers who care about their tools. That means giving you control over your development environment, including the choice to work without AI if that's what works best for you.
That's true for this and many other features of Zed. For example, telemetry can be disabled with a simple switch. However, I feel deeply uncomfortable knowing that my editor is ready to report every file I open, commit I make, code action I perform, etc. at a moment's notice, held back only by that one line in my config file.
You can add firewall block as another line if defense
If you have a moral objection of enabling that feature, you might or might not also have a moral objection of the program having that feature, so I think not everyone does.