I switched from VSCode to Zed
25 points by diktomat
25 points by diktomat
His switch seems in parts to be motivated by AI in VSC, but he seems to like it more in Zed. For anyone not liking it in Zed either, there's a master switch:
{
"disable_ai": true
}
According to the top comment on the orange site, VSC also has a global toggle for AI features: chat.disableAIFeatures release notes
They consider it a bug if any AI features slip through, so they welcome bug reports if any do on their github
That won't save you from the editor itself being "AI" slop, which seems to be the case from looking at the GitHub repository[1].
You should look up the definition of slop. Zed development itself is probably assisted by dogfeeding their own ai features, but the editor is by no means slop or made sloppy.
Updating the meme from "everything I don't like is woke" to "everything I don't like is slop"
Everything generated by copyright laundering text predictors is slop?
I don't think a definition of "slop" that includes everything generated by AI but excludes low-value SEO keyword stuffing blogspam is useful. I think a more useful definition is that slop looks high-effort, but lacks the actual polish associated with it.
I also use Zed when working with Rust, but I'm not happy. It has a bunch of issues that I hit once or twice every few minutes of using it:
A tiny error in code marks massive amounts of code with yellow/red wiggly underlines. I think this may be the language server issue (which I think uses the Rust's front-end, which reports errors in an extremely verbose style), but even if that's true I do wish that the IDE worked around it somehow (maybe parse the error messages) as I can't see anything from all the red/yellow lines while writing the code.
I searched for a way to disable yellow wiggly lines a while ago, which brings me to the next issue:
It's difficult to get help as there aren't a lot of users and a lot of customization options. I've tried Discord, GitHub discussions. If it doesn't work for you out of the box then be prepared to read the source code and just accept its limitations.
Automatic insertion of delimiters (braces, brackets, parens etc.) doesn't work well and it keeps messing with your code. Then you have to manually fix the non-balanced delimiters while the IDE is still actively fighting against you still adding more closing delimiters as you insert new ones. It's extremely annoying. (Note: I don't want to disable it completely, I just want it to work better.... somehow)
Edit: forgot to mention: file finder (ctrl-p) doesn't take frequencies of edited files into account. For certain file names, it always lists a file that I never edit first before all the others that I edit all the time.
I suspect these may all have solutions, but nothing that I could find...
Unfortunately for me, I can't be bothered by endlessly tweaking my editor config anymore and there's nothing that's just perfect for me out of the box.
To 2: I don’t know what problem you want to get help with, I always found everything I need in the extensive and well written docs.
Unfortunately for me, I can't be bothered by endlessly tweaking my editor config anymore and there's nothing that's just perfect for me out of the box.
Guess that’s the same for most people. I prefer existing good-enough over writing my own perfect…
A tiny error in code marks massive amounts of code
Set rust-analyzer.checkOnSave to false
That may help in some cases maybe, but it won't solve the issue. The issue here is that it (analyzer or rustc, I don't know which and don't care) marks too many locations per error, and error locations are large spans of code. It's not that it checks for errors too frequently.
The other reason why it won't help is that Zed by default saves automatically as you modify the buffer. I actually like this feature and don't want to disable it. With this I don't have to manually make sure all my buffers are saved before starting a build/test job.
Take a look at the screenshots, they have very different spans for the same error.
Ah, sorry, I thought you're suggesting enabling "check on save" (i.e. don't check automatically, only when saved).
I now disabled it as you suggest but now it's not showing certain errors at all. For example I just renamed a variable in a function from foo_bar to foobar and I'm not getting any errors in the IDE despite having a few compile errors at the use sites of the variable.
A tiny error in code marks massive amounts of code with yellow/red wiggly underlines.
It should be a rust-analyzer issue. I'm using emacs and suffering the same issue.
See https://lobste.rs/c/mpypm3, but, for emacs specifically, I'd say the best would be to hard-code this setting to false upstream (in eglot or rust-mode). checkOnSave is a polyfill of flycheck/flymake for VS Code, but Emacs obviously can use the real thing.
I have a similar issue (I think?) with Rust in VS Code. The Rust compiler emits a lot of errors like "bad thing happened with foo on line L1, because A happens on line L2, and B happens on line L3, and btw foo is defined on line L4". L1 gets a red highlight, and L2-L4 get blue highlights. I wish there was a way to just have the red lines, but light up the appropriate blue lines when the cursor is on a red line. It's like the concept of "related lines" has become popular with compilers but the LSP/editors still don't get it. Am I missing something?
I'm mainly happy with Zed as an editor that starts fast and stays responsive but isn't mouse-hostile. A rare combo.
One thing it's missing is a simple key shortcut to send the current line or selection to the terminal and hit return. They have a REPL system, but it requires a Jupyter kernel and only displays results inline in the editor file. It's way too involved for a Lispy dev workflow.
I can foresee "switched from Zed to ..." after some time passes.
I think this highlights how important it is to own your tools (maybe owning not as an individual but as a community). This certainly works well in case of vim/neovim and emacs. I wonder why there's no such tool in GUI editors space?
It seems to go the other way 'round, though, with plenty of *vim and emacs users adopting pre-packaged customization setups. So you'll find people switching from e.g. Doom Emacs to LazyVim these days.
This just highlights how such tools can accommodate even such exquisite needs :-)
But anyway, my point is that you can choose to be safe from shoving your way any kind of bloat by just using vim/neovim/emacs. And I'm not talking about using raw/no custom config/plugins, I myself use plugins in neovim. Yes, maybe it requires some upfront work to configure/get used to but it's worth it in my opinion.
Yes, maybe it requires some upfront work to configure/get used to but it's worth it in my opinion.
But that's just the thing: there are other opinions in this matter. Also, your "maybe" is severely downplaying it.
It's worth it for a tool you are going to be using for decades. Why downplaying? I have custom config but I'm not trying to be on top of the latest trends, it just works.
It's worth it for a tool you are going to be using for decades
Like I said, there are other opinions.
Why downplaying? I have custom config but I'm not trying to be on top of the latest trends, it just works.
Nobody said anything about latest trends. "Maybe it requires some upfront work" is downplaying because learning and configuring an old-school editor (esp. in such a way that is supposed to carry you through decades) is absolutely a ton of upfront work.
So its sales pitch is builtin AI slop? So much bandwagoning on this nonsense.
The main sales pitch is the speed and responsiveness: the Zed blog has some good posts on how they optimized rendering.
“Fast and responsive for free; AI tools if you want them” is a considerably better pitch than “slow as tar we’ll keep shoving the AI tools down your throat, good luck disabling them all”
This is literally the first thing on their website
Zed is a minimal code editor crafted for speed and collaboration with humans and AI.
You cannot collaborate with a text predictor, and again “AI” code is just laundered opensource (gpl, etc) code used without complying with the license or giving credit to the actual authors.
This is literally the first thing on their website
Zed is a minimal code editor crafted for speed and collaboration with humans and AI.
It seems that the first thing is speed, collaboration is second, and AI is third.
You cannot collaborate with a text predictor
Actually, why? Collaborative editing is a kind of interactive process that fits certain criteria. Nowhere it does say that your peer in this process must be a human being. You absolutely can "collaborate" with a text predictor, if said text predictor is capable of participating in a three-way I/O loop. Think chinese room — if you, for instance, fully serialize all exchanges during a collaborative editing session with a human, and then train a text predictor to predict these serializations, then you can literally collaborate with a text predictor.
and again “AI” code is just laundered opensource (gpl, etc) code used without complying with the license or giving credit to the actual authors
I am sympathetic to the plight (and skeptical of the "AI" craze), but repeating a hot take does not automatically make it true. Open-source licenses borrow their power from the copyright law. If the copyright law says (or if the courts say) that LLM training is exempt, then it is exempt, and any notion of license (non-)compliance is simply not applicable.
Last time I used it was really fast. Only reason I went back to VS Code was lack of features and inability to configure LSP paths via env variables (I usually use project specific toolchain so there is no global path that I can put into a config file).
If you start Zed via zed . in your project directory, it will inherit the shell’s environment for that window. I use that with direnv and nix flakes; no lsp, build tool etc is in my global $PATH.
This is what I do as well; it would still be nice to have an editor option to reload the environment from a shell though, as right now tweaking or updating a flake means I have to reopen the project afterwards.
Yes but last time I used rust-analyzer didn't pick up rustc from the $PATH. I don't know if that's changed.
I am still highly puzzled about their choice of requiring somewhat recent Vulkan drivers which, so far, has prevented me from even trying it. First on a VM on an i5 from 2013, now on a NUC from 2012 - both perfectly capable of functioning as my personal dev environments. cf https://zed.dev/docs/linux
The jury is still out on how new your graphics card actually needs to be now, but I am not impressed. It's still an editor, and e.g. VS Code runs fine on both my test beds.
After reading this article, I tried Zed for the first time in several months and was pleasantly surprised by many of the improvements it’s gained since my last encounter. However, one VS Code capability on which I’ve long depended, a color picker with preview, still isn’t there and likely won’t be for some time to come:
https://github.com/zed-industries/zed/discussions/31641
... based on this comment from a Zed maintainer:
Yeah, picker is missing still — maybe we need another issue for that, but the main problem will be the design here, and most probably our design forces do not plan to work on this anytime soon.
I'm trying out Zed myself. I started back when it was "super fast editor written in Rust" and was wildly disappointed to see that they've pivoted to an AI slop model, but reasonably happy to see a GUI settings menu (which is new since I last tried it) with a prominent "Turn AI Off" switch. That's the only reason I kept trying.
Given that what I want is Emacs but with a modern GUI -- and it seems I'll simply never get that -- Zed and Gitu have been an interesting alternative. I can't say that I'll abandon Emacs my beloved anytime soon, but having choices is never bad.