I'm generally a big fan of zed and have been using it for 60%ish of my dev time for 6 months or so. A couple of nice things to note:
- It really is remarkably responsive,and makes one really notice how UNresponsive everything else is. I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising. VSCode never felt slow on my macs until I started using Zed.
- They seem reasonably responsive to feedback. There was some contention around how search/replace was initially implemented, and the current builds have something much more usable IMO. I'm not sure how much that was driven by community feedback, but the changes were great.
- The debug syntax tree mode is a really neat feature that I think demonstrates how much more advanced zed is under the hood than older editors that are doing syntax highlighting via regex.
There are a few downsides that I'm hoping get addressed soon:
- The collaboration workflow/security isn't very clear to me. You sign in via github (no other option???), there are 'contacts' (I guess these are github usernames?), and 'channels' (where do these live? on zed's servers?). I would really like to know if I can self-host the chat server and use a company oauth provider rather than github. If the diffs being passed around are going through zed's servers, that may be a showstopper for the company I work for as well. If they're p2p and encrypted, maybe not.
- I would love to see ollama integration. This + continue is the only reason why I spend any amount of time in vscode now. There's an issue for it here: https://github.com/zed-industries/zed/issues/4424
I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot.
But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck: I think it’s a front runner there. But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS.
People are asking what settings would be useful to tweak. Check out the following:
- gcmh -package and gcmh-mode and/or gc-cons-threshold variable (former should take over the latter)
- read-process-output-max
- jit-lock-defer-time
- package-native-compile
Doom Emacs sets gcmh in its initialization so tweaking that might not be needed there. You may still want to touch gcmh-high-cons-threshold and gcmh-idle-delay-factor. Here are mine currently:
I've done nothing scientific to check out if these help at all, though, so take them with salt. With and without these, emacs seems quite sluggish at least on a Macbook, in certain modes. On Linux things seem to be a bit better.
How do you get a reasonably fancy Emacs to start up/open files quickly? Every time I try to get into EMacs after adding a few packages it becomes painfully slow to open a file for editing. Then I try to understand Emacs server, then I fail / give up and go back to vim.
> There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck
Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.
One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).
>>But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.
VSCode has always felt incredibly slow to me, even compared to e.g. pycharm. , which I have always assumed of be otherwise roughly comparable. VSC’s lag in basic code inspection and linting became so annoying I had to switch off it. We’re not talking seconds, but maybe tenths of second lag, for everything at all times. I understand plenty of people love VSC, but honestly I have never been able to share that enthusiasm.
Yep. For some reason, suddenly, vscode became painfully slow on my decently spec'd machine; 3 to 7 seconds per keystroke just to analyse the file to show intellisense tooltips.
Yes, that was in seconds per keystroke.
The irony is that I moved from neovim to vscode because setting up intellisense in (neo)vim was always a hassle and never worked quite well. Pylance seemed too attractive not to give it a spin.
Now the lag has as mysteriously diminished, but still vscode is very far from being as snappy as (n)vim.
Ive been wanting a syntax-tree-viewer for months, to help me learn functional languages where figuring out what is even going on syntax-wise in the exmaples provided by tutorials keeps being an issue for me.
Does anyone know of a way to see a syntax tree for any given snippet of code for any given language? I'd try Zed, but I'll have to wait for Linux support.
I am not sure what debug syntax tree mode does in Zed, but if it's about tree-sitter generated syntax tree, you can see that in Neovim or Emacs (assuming you have major-mode/grammar loaded):
> older editors that are doing syntax highlighting via regex.
I mean, Emacs, which can probably be considered the oldest code editor at this point, got built-in tree-sitter (which is what Zed uses under the hood) support in the last release. So it's not really related to editors being new or old
It's not just tree-sitter that makes zed feel snappy.
If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode), the autocomplete & intentions feel instantaneous.
I think the team has learned a lot from previous editor implementations (they were the core team of atom that was notoriously slow), and so they've had an opportunity to do a lot of stuff right.
FWIW they also are the team that originally wrote tree-sitter.
The quickness feels more like it's in the core of the editor. I was shocked how much it impacted the editing experience when I tried it in early beta.
As I understand, tree-sitter implementation in Emacs is currently more like a foundation for development / adoption by plugins, it's not really usable as-is today.
>>I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising.
I really envy people who can sense passage of time between intervals of 5 milliseconds and 500 milliseconds.
My sensibility begins over a second. And to be honest even that is least of my issues. Same with start up time, I restart the IDE only once in a few days. I thinking spending a second or two extra for it is any where in the ball park of what I would call wasting time.
I use this extension: https://continue.dev/ their docs are pretty good, but it's also evolving pretty rapidly. For example, you no longer need to run the continue server yourself, it's entirely self contained in the vs code extension. I believe the docs still refer to how to run it manually.
I work for a pretty conservative company re: GAI, and the ollama + continue combo made it through legal.
I switched _to_ VSCode because Sublime was occasionally so slow at times that it was unusable. It was very fast 95% of the time, but then I'd `git pull` on a very big repo and my machine would become unresponsive while Sublime did...something.
Not in 15ish years and at the time I think I had a 5400rpm hd, so that probably limited any perception of sublime being noticeably faster than other editors I was using (geany, kate). I don't doubt that sublime is faster than vscode today, but the vscode ecosystem is a pretty nice place to be and probably worth trading some speed for, especially on a nice mac where the trade off is probably small. Zed might be even better however.
Or vim, I suppose. It's remarkable how slow VSCode actually is, but I still use it because I hate configuring vim and packages always break when upgrading, it's honestly worse than npm.
> GPL for the editor, AGPL for server-side components). GPUI, the UI framework that powers Zed, will be distributed under the Apache 2 license, so that you can use it to build high-performance desktop applications and distribute them under any license you choose
Interesting choice on licenses.
—-
I’m been super happy with Zed, my main requests (and I’ve sent in this feedback to them or contributed to existing GitHub Issues)
a. Window Size & Position doesn’t persist after closing Zed.
b. I constantly run into Language Server errors
c. Alabaster use to work as a theme, doesn’t anymore. Would be great if you could import VSCode themes into Zed
All above has tickets open.
----
Hope these small things get addressed because I truly love the elegant UI design of Zed
For those who haven't used Zed, it's the first GUI editor I've used in 25-years of development that wasn't distracting.
It's hard to describe how much more focused I am when not distracted with a Christmas tree scene of icons, menus, colors, etc. like you see in other editors.
Zed is very calming, due to its focus on not having distractions. Give it a try if you haven't.
The licensing choice is smart. "Permissive" licenses permit closing off something built largely on the work of the open source community.
Zed is made by the Atom guy and the Tree Sitter guy. Atom was MIT licensed. I wouldn't be surprised if he's thinking the MIT license is the path to VS-Zed.
This tripped me up as well, you need to set up the language servers in your settings json. There are examples in the Configuring Zed section of the Docs area on the site.
Funny you mention that because I felt Zed had _too many_ buttons & icons for things compared to Sublime Text. I feel they could do without the dedicated stuff for GPT/Copilot and others, and sweep them away to the command palette.
I opened a random python project on my machine in Zed and it automatically loaded up an LSP for python. It looks like it's using the same one as my emacs uses (pyright), but it presents completion choices in a not particularly useful order. Typing `os.p` gives me for instance as completion choices:
Is pyright just giving Zed all the possibilities and it's up to Zed to rank them? I don't know the details of editor/LSP integration. lsp-whatever in emacs ranks these choices in a reasonable order.
I’m also curious about the answer to this! I noticed similar behavior when opening a Typescript project. Enjoy the low latency, but I’d also appreciate accurate/helpful autocomplete suggestions.
Yeah, I noticed while writing Typescript that it was suggesting `String` above `string`. In Javascript and Typescript, there are almost no situations where `String` is the correct thing to use, so this choice surprised me.
I tried it out today, and in all fairness it is a very attractive and pleasant-to-use editor, but it felt like it was missing a lot of the little details. Things like suggestion order, or being able to open terminals side-by-side, or showing quickly where all the type errors are in my project or even a single file.
The collaboration tools sounds really neat, but unless I can convince colleagues to use it with me, I don't have anyone to collaborate with! For that, the little details are hugely important.
That said, it looks and feels wonderful, it's a very elegant tool.
Hey! Thank you for this cool editor! However, has it been written with cross-platform support in mind? Otherwise, porting from mac to linux could be rather painful and time-consuming... Will there be an ETA for us linux users? I saw it on the roadmap [0] but without an ETA.
Speaking of Linux, are there any other editors we can use today? I tried to look for one recently but couldn't find anything. (edit: I mean collaborative editors)
Gobby is mostly dead but still works. Win/Linux; macOS builds have gotten harder now that it's been about 3 years since the last release: https://gobby.github.io/
EDIT: It's apparently on Macports as of quite recently, though the port health for recent macOS releases looks bad.
AI helpers, Chats and Calls??? Microsoft log-in, Commercial plans, Telemetry? Seems like an overload of everything for an editor - more distractions not a new way to code. Def sticking with good old nvim for some longer time, no better editing experience engineered yet
Really nice and fast (which is the reason I’m still using Sublime instead of VS Code). I’ve only found one piece of functionality that’s dramatically slow compared to Sublime so far: selecting all of the current highlight. In my current file I have 2,396 occurrences of `<span>`. Selecting all of them in Sublime (with ctrl + cmd + g) is certainly less than 200ms. Doing the same in Zed (with cmd + shift + l) beachballs my machine for around 5 secs.
For most code work that’s probably not a situation to optimise for, but I often work on large markup documents.
Zed developers, if you read this, please get inspired by Cursors "Fix it" button that you can click on any error. It simply starts a new chat with the code context and error message, suggesting possible fixes.
I'm currently learning Rust and this is such a powerup that I honestly wouldn't know how to learn anything without.
> Zed supports GitHub Copilot out of the box, and you can use GPT-4 generate or refactor code by pressing ctrl-enter and typing a natural language prompt.
https://zed.dev/
Seems like that ship has sailed. Maybe it's a plugin already or could be in the future, but that's not on GP's suggestion.
Beyond "is it on by default" (due to data privacy concerns) whether something belongs in a "core" editor or in a plugin is a whole separate can of worms - moreso if the core editor starts shipping plugins. There is someone who reads that agreeing it means the editor should be just a plugin store and if you want font hinting, syntax coloring, tabs, terminals, smooth scrolling, and so on then download them yourself. At the same time there is someone who reads that agreeing it means the editor should have anything possible related to working with text but if you want to play a video while you code the plugin system should allow you to do that in a pane. Neither are really right or wrong about what should be a plugin, it's really a matter of what the tool wants to optimize for out of the box.
I've been following Zed for quite some time now and happy to see them follow through with the OSS move.
I personally don't like for my editor to send out any kind of external requests at all, and this is actually what keeps me on vim as my main editor. I also don't like limited login options
It would be cool to have a version that's just a stripped down Zed, and if need be you can install the extra stuff as plugins.
Readit News
- It really is remarkably responsive,and makes one really notice how UNresponsive everything else is. I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising. VSCode never felt slow on my macs until I started using Zed.
- They seem reasonably responsive to feedback. There was some contention around how search/replace was initially implemented, and the current builds have something much more usable IMO. I'm not sure how much that was driven by community feedback, but the changes were great.
- The debug syntax tree mode is a really neat feature that I think demonstrates how much more advanced zed is under the hood than older editors that are doing syntax highlighting via regex.
There are a few downsides that I'm hoping get addressed soon:
- The collaboration workflow/security isn't very clear to me. You sign in via github (no other option???), there are 'contacts' (I guess these are github usernames?), and 'channels' (where do these live? on zed's servers?). I would really like to know if I can self-host the chat server and use a company oauth provider rather than github. If the diffs being passed around are going through zed's servers, that may be a showstopper for the company I work for as well. If they're p2p and encrypted, maybe not.
- I would love to see ollama integration. This + continue is the only reason why I spend any amount of time in vscode now. There's an issue for it here: https://github.com/zed-industries/zed/issues/4424
But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck: I think it’s a front runner there. But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS.
- gcmh -package and gcmh-mode and/or gc-cons-threshold variable (former should take over the latter)
- read-process-output-max
- jit-lock-defer-time
- package-native-compile
Doom Emacs sets gcmh in its initialization so tweaking that might not be needed there. You may still want to touch gcmh-high-cons-threshold and gcmh-idle-delay-factor. Here are mine currently:
I've done nothing scientific to check out if these help at all, though, so take them with salt. With and without these, emacs seems quite sluggish at least on a Macbook, in certain modes. On Linux things seem to be a bit better.Congratulations for winning HN sentence of the year before the end of January.
I can't parse this sentence -- could you unpack it? Not being a dick, I really want to know what you mean.
Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.
Please share how.
Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.
One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).
That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.
Yes, that was in seconds per keystroke.
The irony is that I moved from neovim to vscode because setting up intellisense in (neo)vim was always a hassle and never worked quite well. Pylance seemed too attractive not to give it a spin.
Now the lag has as mysteriously diminished, but still vscode is very far from being as snappy as (n)vim.
1) In Neovim, do `:TSPlaygroundToggle`
2) In Emacs, do `M-x treesit-explore-mode`
I mean, Emacs, which can probably be considered the oldest code editor at this point, got built-in tree-sitter (which is what Zed uses under the hood) support in the last release. So it's not really related to editors being new or old
If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode), the autocomplete & intentions feel instantaneous.
I think the team has learned a lot from previous editor implementations (they were the core team of atom that was notoriously slow), and so they've had an opportunity to do a lot of stuff right.
FWIW they also are the team that originally wrote tree-sitter.
The quickness feels more like it's in the core of the editor. I was shocked how much it impacted the editing experience when I tried it in early beta.
It’s very early, but I’ve been building a “trigger command/script and have it output anywhere” project that you could use as a bandaid solution.
I added Ollama support (you can specify model in settings)
https://github.com/jasonjmcghee/plock
It works wherever you are
I really envy people who can sense passage of time between intervals of 5 milliseconds and 500 milliseconds.
My sensibility begins over a second. And to be honest even that is least of my issues. Same with start up time, I restart the IDE only once in a few days. I thinking spending a second or two extra for it is any where in the ball park of what I would call wasting time.
I work for a pretty conservative company re: GAI, and the ollama + continue combo made it through legal.
I guess you haven't used Sublime Text before?
That and self updating in ways that broke my most important plugin.
Deleted Comment
Interesting choice on licenses.
—-
I’m been super happy with Zed, my main requests (and I’ve sent in this feedback to them or contributed to existing GitHub Issues)
a. Window Size & Position doesn’t persist after closing Zed.
b. I constantly run into Language Server errors
c. Alabaster use to work as a theme, doesn’t anymore. Would be great if you could import VSCode themes into Zed
All above has tickets open.
----
Hope these small things get addressed because I truly love the elegant UI design of Zed
For those who haven't used Zed, it's the first GUI editor I've used in 25-years of development that wasn't distracting.
It's hard to describe how much more focused I am when not distracted with a Christmas tree scene of icons, menus, colors, etc. like you see in other editors.
Zed is very calming, due to its focus on not having distractions. Give it a try if you haven't.
Zed is made by the Atom guy and the Tree Sitter guy. Atom was MIT licensed. I wouldn't be surprised if he's thinking the MIT license is the path to VS-Zed.
I love jetbrains because it’s so feature rich and helps me a ton but god damn it’s slow.
As you say the interface is elegant and distraction free by default, no twiddling required to get a happy place.
So far I've only used it for my personal projects and don't yet have full muscle memory, but weirdly even the keyboard shortcuts seem more intuitive.
Is pyright just giving Zed all the possibilities and it's up to Zed to rank them? I don't know the details of editor/LSP integration. lsp-whatever in emacs ranks these choices in a reasonable order.
I tried it out today, and in all fairness it is a very attractive and pleasant-to-use editor, but it felt like it was missing a lot of the little details. Things like suggestion order, or being able to open terminals side-by-side, or showing quickly where all the type errors are in my project or even a single file.
The collaboration tools sounds really neat, but unless I can convince colleagues to use it with me, I don't have anyone to collaborate with! For that, the little details are hugely important.
That said, it looks and feels wonderful, it's a very elegant tool.
[0] https://zed.dev/roadmap
Anyway, the VSCode plugin ecosystem is probably your best bet there: https://code.visualstudio.com/learn/collaboration/live-share
There's a whole list here: https://wiki.archlinux.org/title/List_of_applications/Docume...
EDIT: It's apparently on Macports as of quite recently, though the port health for recent macOS releases looks bad.
For most code work that’s probably not a situation to optimise for, but I often work on large markup documents.
I'm currently learning Rust and this is such a powerup that I honestly wouldn't know how to learn anything without.
If people want this just let it be a plugin.
Seems like that ship has sailed. Maybe it's a plugin already or could be in the future, but that's not on GP's suggestion.
Deleted Comment
Dead Comment
I personally don't like for my editor to send out any kind of external requests at all, and this is actually what keeps me on vim as my main editor. I also don't like limited login options
It would be cool to have a version that's just a stripped down Zed, and if need be you can install the extra stuff as plugins.