About the multithreaded thing: it's not as if everything was single-threaded. There are cases where Emacs shall offload the work to something working in the background. Be it a LSP server or generating thumbnails for a directory with thousands of pictures seen from image-dired: Emacs is totally usable while other processes / async calls are doing their things in the background.
> the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone
And now that Microsoft created LSP (IMO not because they're kind hearted but as a totally dick move to piss off JetBrains who was gaining too much developers momentum and becoming a threat to the "developers, developers, developers" mantra) and that Emacs supports LSP, suddenly those things an IDE did really better than Emacs are much smaller. I'm not saying there aren't a few things an IDE from JetBrains shall be better at than Emacs for a particular language: but on average the gap on those things got way narrower. And Emacs can do a shitload of things an IDE doesn't: configuration/tailoring to your way of working comes to mind. I wrote an IntelliJ plugin back in the days: not fun. I much prefer to write elisp to enhance Emacs.
I was using IntelliJ IDEA back before some commenting here were born: I was an early IntelliJ IDEA adopter (when it was barely usable on Linux btw). But I never stopped using Emacs.
Every other IDE became slower and "piggyer" at a rate outpacing the now dog-slow advances in CPU/RAM on personal computers (I'm running an AMD 7700X atm, so not too bad of a machine). Meanwhile at every single release Emacs became more efficient. The switch to "native complication" was a gigantic speed boost.
As I like to point out: the "Emacs meaning Eight Megabytes And Constantly Swapping" joke was true back in the frigging nineties. Yup, on a 486 with 8 MB of RAM it was quite something to run Emacs.
But nowadays we all have about 16 to 64 GB of RAM on our systems. And Emacs is still Emacs.
When something survives decades and has stuff like Magit and org-mode which many revere, it has to do something right.
If there's a problem with elisp is that it's... Old? But it did survive. It is usable. It's problems and how to work around them are well known.
And it's rock stable. My custom Emacs/elisp code configuration is about 3 000 lines of elisp. I think I made one change/commit in six months to my Emacs configuration. It's that solid.
> At the very least if it all comes down to a dick measuring contest ...
Oh also... At times I have Emacs' uptime surpassing that possible of a Windows consumer OS (which needs to be rebooted regularly due to mandatory updates).
Basically the only time when I reinstall Emacs is when I upgrade to either the new Debian stable distro or when I upgrade to a new PC: when it comes out, I install it (I prefer to install from scratch, YMMV) and then use the opportunity to fetch the latest Emacs and compile it from source. I don't remember the last time I did it: it was when Debian 12 stable came out.
> the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone
And now that Microsoft created LSP (IMO not because they're kind hearted but as a totally dick move to piss off JetBrains who was gaining too much developers momentum and becoming a threat to the "developers, developers, developers" mantra) and that Emacs supports LSP, suddenly those things an IDE did really better than Emacs are much smaller. I'm not saying there aren't a few things an IDE from JetBrains shall be better at than Emacs for a particular language: but on average the gap on those things got way narrower. And Emacs can do a shitload of things an IDE doesn't: configuration/tailoring to your way of working comes to mind. I wrote an IntelliJ plugin back in the days: not fun. I much prefer to write elisp to enhance Emacs.
I was using IntelliJ IDEA back before some commenting here were born: I was an early IntelliJ IDEA adopter (when it was barely usable on Linux btw). But I never stopped using Emacs.
Every other IDE became slower and "piggyer" at a rate outpacing the now dog-slow advances in CPU/RAM on personal computers (I'm running an AMD 7700X atm, so not too bad of a machine). Meanwhile at every single release Emacs became more efficient. The switch to "native complication" was a gigantic speed boost.
As I like to point out: the "Emacs meaning Eight Megabytes And Constantly Swapping" joke was true back in the frigging nineties. Yup, on a 486 with 8 MB of RAM it was quite something to run Emacs.
But nowadays we all have about 16 to 64 GB of RAM on our systems. And Emacs is still Emacs.
When something survives decades and has stuff like Magit and org-mode which many revere, it has to do something right.
If there's a problem with elisp is that it's... Old? But it did survive. It is usable. It's problems and how to work around them are well known.
And it's rock stable. My custom Emacs/elisp code configuration is about 3 000 lines of elisp. I think I made one change/commit in six months to my Emacs configuration. It's that solid.
> At the very least if it all comes down to a dick measuring contest ...
Oh also... At times I have Emacs' uptime surpassing that possible of a Windows consumer OS (which needs to be rebooted regularly due to mandatory updates).
Basically the only time when I reinstall Emacs is when I upgrade to either the new Debian stable distro or when I upgrade to a new PC: when it comes out, I install it (I prefer to install from scratch, YMMV) and then use the opportunity to fetch the latest Emacs and compile it from source. I don't remember the last time I did it: it was when Debian 12 stable came out.