I can also vehemently endorse Andrea Corallo's work on native-comp/libgccjit. The compilation can be finicky so I recommend looking at the AUR script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs... or this lovely article: https://www.masteringemacs.org/article/speed-up-emacs-libjan...

Also, for those of you who didn't know what GCMH was:

https://github.com/emacsmirror/gcmh

> GCMH - the Garbage Collector Magic Hack

> Enforce a sneaky Garbage Collection strategy to minimize GC interference with user activity. During normal use a high GC threshold is set. When idling GC is triggered and a low threshold is set.

I used Emacs from 2012-2018.

I originally started using Emacs because its haskell-mode and erlang-mode beat anything out there. (I stayed for a lot of other things, too.)

I stopped using Emacs because of its poor LSP support. VSCode's Haskell LSP was better.

I briefly tried to reboot using Doom Emacs for Rust development this year, but the LSP support was still quite terrible.

There are reasons to stop using something after 10 years.

(Also, I've been using Vim on the side 1997-now. It never dies, but I never turned it into an IDE.)

Just help improving it. There are many reasons to stick with something after a decade, especially something as powerful as emacs. LSP support is fixable.

I’m not interested in writing Emacs Lisp. It is not just the lack of LSP support, but also that after 6 hours of configuring, I don’t have an IDE that just works. VSCode, Zed and Neovim all have less legacy and fewer moving parts I need to be concerned about when starting from scratch.

In my opinion there is too much to fix for me to enjoy Emacs, compared to the alternatives.

That is a big ask when one could instead be productive using VSCode which has fantastic LSP support and use emacs or vim keybindings in that IDE for editing without having to retrain muscle memory.