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.
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.
Open it at 8am, close it at 8pm
Hahahaha. A dev I work with who has been using eMacs for 30+ years is well known at my company for having eMacs sessions open for 6+ months at a time.
I’d rather open at 8am, close on kernel upgrade.
At least that’s how I worked with my vim tmux sessions ;)
Emacs server is quite straightforward. M-x server-start in a running emacs, then emacsclient <filename>. emacsclient -c if you want to open the file in a new window, or emacsclient -t if you want to open it in your current terminal. C-x # when you're done editing the file.
myhome>> emacs --daemon
Use doomemacs for a start. It really optimizes startup time and offers vast included modules as well as great package management. https://github.com/doomemacs/doomemacs/blob/master/docs/gett... Oh and for Windows, WSL2 seems to be the fastest: https://github.com/doomemacs/doomemacs/blob/master/docs/gett...
Doom is a great start for a low-friction, extreme quality curated emacs setup. +1
I've been using emacs as my main editor for years now and don't find the startup speed to be an issue - to the point I've never bothered with emacsclient:
It starts up with ~77 packages in half a second.
This is my config.
https://gitlab.com/ideasman42/dotfiles/-/tree/main/.config/e...
That’s pretty close to what I’ve been running on the GC tuning but I like parts of your spelling better.
This is going MIT as part of a bigger project in about a month (think Lucid s/C++/modern models/).
If I inline attribution you mind if I borrow this or that?
https://imgur.com/a/i99Nisn
1.4 seconds for 100 packages, half of which are on probation? My (and soon `HYPER//MODERN`'s) package set is under heavy construction, I'll be sad if I don't get it under 300ms including loading and rendering a logo at 6k from a cold disk which that was.
Rust is a perfectly good language for writing tight code, but those `emacs` inner loops have been tuned by hard-ass pros for 30+ years in straight C, which is plenty fast too. Even the best Rust code doesn't have that kind of tuning in.
`emacs` is fucking fast.
With no intention to push back on Emacs being highly optimized, age of an application is not an accurate proxy for level of performance. If it were, grep would be faster than ripgrep. New software can apply optimisations discovered over the previous 40 years, and leverage architectural designs with different assumptions, like the GC limits in Emacs discussed elsewhere in the comments. Older applications can apply those same optimizations, but it's not a given that they will, and changing their architecture can be daunting, for sometimes unknown benefits.
I was about to answer "Use emacsclient", but then I realized you can't be bothered to configure it. For me, putting "(server-start)" into .emacs was always enough, but YMMV.
Emacs still blocks input on simple things like package updates though.
Give straight.el (among others) a shot. Combined with use-package you don’t have to worry about that these days.
Ah ok. Last time I used straight it still blocked input on straight-update-all, didn’t realize they changed this.
There's a little tweaking sometimes.
Most examples you'll see of `straight.el`/`use-package` configurations will have some version of: `(use-package something-cool :ensure t :config ...`. The `:ensure t` clause will cause it to fall back on `package-install` in the event it's not bolted into your local Cargo-style-own-the-world-and-dont-break repo mirror. Disks are big, it's like the right default now.
But if you've got a package that's mis-specified in terms of where on `github` or wherever that `striaght` is supposed to find it, you can find it tapping `elpa.org` on the shoulder at a time when the UI thread is also doing blocking network IO.
The `Messages` and/or `straight` buffers will have warnings about this, so it's fixable to find the offending package and it'll stay fixed, but in fairness what you're describing is possible.
Elpaca [1] does not do this. I use it and it works a treat.
1: https://github.com/progfolio/elpaca
Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.
The, uh, GNU folks, are a little conservative in some ways that surprise the mainstream developers. But there are always flags for it. Well, except stupid-ass dynamic-linking of `glibc`.
Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)
You would think that it would dynamically check the system on first run and set appropriate defaults.
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.The thing about gc-cons-threshold is that, too low a value and it will collect garbage too frequently. While a high value will drastically reduce frequency, but then GC pause will be big and you will likely feel whole system freeze and stutter when it happens. For me, 1GB is too high because I sorta notice the pause, I set it to 32MB but completely disable GC when minibuffer is active:
Eli Zaretskii (current Emacs maintainer) also thinks 1GB is too high, though for somewhat different reason:https://old.reddit.com/r/emacs/comments/bg85qm/garbage_colle...
Here is an interesting optimisation that was merged in master, but didn't make the cut for 29 in time. I thought it improved snappiness:
https://tdodge.consulting/blog/living-the-emacs-garbage-coll...
---
Anyway, I also have these in my init (I nicked these from Doom which I don't use but they have done a lot of work to dive deep into these things, mostly around what improves start up but the following might help in general):
I’m doing different heap sizes during package load, but I don’t have the mini buffer hook and in retrospect, I feel dumb.
If I do inline attribution you mind if I borrow that under MIT?
Go ahead. Though I don't think attribution is even necessary for something I myself may have borrowed from somewhere.
Please share how.
i got annoyed by emacs gc pauses and just disabled the gc completely (i think). haven't noticed any downsides so far. i'm in emacs all day...
something i love about emacs is everything is implemented in the same abstraction (of a "buffer of text"). so i can manipulate and move around an embedded terminal in the same way as a normal file, etc.playing briefly with Zed it seemed like the terminal was a totally different "thing" than a normal file; i couldn't run the same text selection operations, couldn't split the window vertically or horizontally, etc. to me that loses a ton of the benefit of having a terminal in the editor in the first place.
still, it's a very interesting project. i have a very love/hate relationship with emacs, so i'm always interested in alternatives...
Both @darthrupert and @natyrys on the thread have said most of what I know. It's a little machine dependent to get the true sweet spot, but raising it from the like, megabyte (slight hyperbole) or whatever that it defaults to is the 80/20.
Congratulations for winning HN sentence of the year before the end of January.
It is a great sentence, and that holy shit moment is coming: when JS gains all the expressivity of tree-sitter and uses it to render code more beautifully than it has ever been rendered before.
(Spoiler: https://github.com/bablr-lang/)
I’m glad I made a funny but it’s a lot of year to come :) And this one looks to be every bit as interesting as the last one was over-hyped.
Can you share more about your Emacs 29 setup? Thanks
I mentioned it above but I’m flattered by your interest (and remember your username as someone serious): my old dots were ok and are floating around but we’re putting together a multi-editor curated setup for good defaults and an emphasis on good, available-weight models as first-class citizens.
It’s a 404 until I get to an RC, but aiming for March 1st on “hyper-modern.ai” for all MIT on emacs, nvim, and vscode.
I can't still figure out how can I get Emacs not mess up indentation and auto indentation.
Most language modes have a `foo-ts-mode` now that uses `tree-sitter` to get a perfect* AST in the absence of errors, and almost always the most reasonable one in the presence of errors. `tree-sitter` is amazing, a real feat.
It ships with 29 and it's work to find `brew` or `apt` or `nix` or anything giving you less than 29.1 these days.
Have you tried a recent version? 29.1 is dramatically more accurate on everything from syntax highlighting to indention than VSCode (IMHO, they're probably either using or working on using `tree-sitter` too, those are serious people) or JetBrains stuff (they're working on their vscode clone more than IntelliJ these days).
I only use `nvim` for commit messages and stuff the last few years, but AFAIK it has all the `tree-sitter` stuff too.
If it's the sloppy naming of `c-basic-offset-this` vs. `py-indent-that` or whatever (I don't even remember), try a good baseline distro like Doom and tweak from there.
what are the right flags and gc tunings?
I don’t have much to add on what sibling @darthrupert said. You tweak this or that to your box but that’s an excellent guideline to start.
Yes you are correct
That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.
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).
I guess you haven't used Sublime Text before?
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.
This is very strange to me, because I have always used Sublime Text for super-giant corporate repos, and always found it snappy compared to vscode. Wonder if it was a specific usecase or something...
Every little while, I try to make vscode my main editor, because I enjoy all the features. I always switch back to Sublime just because VSCode's slowness bugs me.
Haven't really tried Zed in earnest yet, though, because of no custom LSP support.
I'll be eager to try Zed when it gets LSP support for sure
Sublime Text 4166 has some major improvements in that area, previously ST would check every file in the side bar for changes in order to update its index but this is now done incrementally.
I think on Linux at least it freezes due to watching too many files using inotify to update its sidebar. I wish there was an option to disable that. Same thing happens with Sublime Merge. It’s unusable on giant repos.
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.
Are you sure that’s vim rather than Melvin. Never had any issues with anything breaking on an upgrade using vim.
Not sure what Melvin is. I've always had issues, specifically when I have lots of packages, such as when installing stuff through lazy.vim.
Updating vim packages can be a nightmare if you don't vet your plugins and generally install stuff "just in case I want to try it out later". If you aren't using a plugin with any regularity, delete it.
I had to stop using sublime because it kept updating its search index at inconvenient times and slowing to a crawl.
That and self updating in ways that broke my most important plugin.
I was hitting that bug for about 6 months, but at least for me they have actually fixed it now.
I’m still using Sublime for the references. Without fail I can load up any version of an application including older rails apps sub 3 and it instantly has context. I can easily jump to definitions and even on hover will show me where they are being used. In the context of foos.bars.baz I could easily infer where bars is defined. Seems to work across languages, doesn’t matter if it’s js, ruby, in an erb file it just works. Not to mention the flavor of vim feels great.
VSCode complains and I’ve got to hardcode an alternative absolute path gemfile for Shopify’s LSP to work. It also feels clunkier, even on powerful machines.
If Zed can give parity with Sublime on the references (I just tried and it did not seem to find any references when clearly bars was there) might be an interesting change. Considering it’s open source now I’d happily switch as it does seems super quick.
I might also be old-man yells at cloud and the copilot integration doesn’t appear important yet, but current sublime support is pretty poor for it and seems like that’ll be a thing more and more.
or BBEdit.
That’s where I landed after v14 with LSP support came out. It’s so nimble! And extensions with shell scripts and CLI programs is right in my wheelhouse.
Cries in PhpStorm
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.
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.
I've been impressed with the C++ clangd language server snappiness in Zed compared to both CLion (my old favorite) and Emacs (apple of my eye for 2.5 yrs).
I always thought the major slowness was coming from clangd itself, so I'm surprised and impressed to see that Zed appears to be quicker on this front. I might be using Zed as a 'second opinion' editor because of this.
However, now I'm used to the infinite customizability and coziness of Emacs, it's going to be hard for me to move across to Zed permanently.
Emacs have some issues with LSP speed because of the json parsing not being the fastest which have lead to work like this: https://github.com/blahgeek/emacs-lsp-booster.
Ah, thanks for the link, I hadn't seen that. I will give Eglot another go with this set up!
Some more anecdata to back this up: initial workspace load in VScode I can watch RA tick through its progress. Clean and boot up Zed and the same process is so fast that it’s almost unbelievable.
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.
Emacs already had tree-sitter before 29, just not built in. You can do syntax highlighting[1] and structured editing with it.[2] What is missing for it to be usable in your view?
[1] https://emacs-tree-sitter.github.io/syntax-highlighting/
[2] https://github.com/meain/evil-textobj-tree-sitter
Your understanding is outdated/incorrect. Already a number of major modes have corresponding ts modes and I use them daily. This includes C++, Rust, Python, yaml, toml, json, Java, typescript, dockerfile and cmake. True not every major mode has treesitter in the official release but I’d hardly call the above “not usable”
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.
how to you use ollama with vscode? some links/ details would help me a lot!
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.
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):
1) In Neovim, do `:TSPlaygroundToggle`
2) In Emacs, do `M-x treesit-explore-mode`
Now I wonder what's the typing lag of 10xeditor, compared to Zed...
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.