> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner.
I disagree with this point. Emacs does not have a useful process model, or at least it cannot be used to the full extend, because of shared global mutable state. This is exactly the issue, not a practical thing. If it were not for all the usage of mutable (and mutated) global state, Emacs could actually benefit from running many things concurrently, without annoying users with blocking behavior.
This is of course a huge task to refactor Emacs like that. I can only hope, that some day we will get there, because I see it as one fatal flaw, that could over time kill Emacs. Yes, Emacs as it is is super useful, but more and more things come up, that will be better off running concurrently and in parallel. Just to name a few: Package compilation, waiting for LSP stuff, anything that waits for network, like tramp, running source blocks in org-mode (org-babel), syntax highlighting of big files, magit stuff like rendering huge diffs in a magit status buffer ...
All of those things could benefit from being able to use multiple cores and improve Emacs' snappiness and speed. All of these come before even changing anything about elisp the language.
I would say that proper threads with shared mutable state would make things much more fragile and high-ceremony, with locks, atomics, and potential races everywhere. For real multi-core performance gains, I would much prefer a model like JavaScript's workers, or Python's multiprocessing, with easy but explicit shared memory interface where message passing with serde does not suffice.
I'm pretty sure out of the box, Emacs can native compile packages in parallel ( https://www.jamescherti.com/emacs-native-compilation-config-... ) unless I'm misunderstanding something. Elpaca, which is the package manager I use, can download and install packages in parallel. lsp-bridge intercepts Emacs' LSP client and in my experience significantly reduces perceived latency for clangd.
I have always found this view interesting. Emacs has been able to run external tools with sentinels for a long time. Compilation mode being the easy example to show this.
It is somewhat cumbersome, no doubt, but for all of the code that didn't decide to use that and can easily cause emacs to stall, I see no reason to think we won't have as much or more problems with multiple threads.
If I understand correctly, sentinels (https://www.gnu.org/software/emacs/manual/html_node/elisp/Se...) are about external processes, like running a shell command concurrently. So for example one can run a `git status` in a separate process and have a sentinel for that. Now if I think about magit, it might very well run some git status, but what about rendering a huge diff in the magit status buffer? Can such a thing even be done in an external process? Or does that necessarily stall Emacs?
There are a few things here. You are correct that this is for external processes. You are further correct that you can push the heavy part of a diff and such to an external process.
At that point, you have the textual output in a buffer and you want emacs to simply render that buffer in a "pretty" way. This is done for many things, grep being one people are most familiar with in emacs. It can recognize each match with enough detail to let you jump to the file it is in. I don't know how magit renders diffs, but I'd imagine it should work roughly the same way. Probably leaning on some other elisp to allow common editing.
My point holds that more and more languages have server protocols that would be akin to an external process, now. In this way, there is little benefit in reimplementing a ton of stuff in the emacs process. Especially with the standardization of leaning on json, the link to the external process can be a textual buffer just fine.
I disagree with this point. Emacs does not have a useful process model, or at least it cannot be used to the full extend, because of shared global mutable state. This is exactly the issue, not a practical thing. If it were not for all the usage of mutable (and mutated) global state, Emacs could actually benefit from running many things concurrently, without annoying users with blocking behavior.
This is of course a huge task to refactor Emacs like that. I can only hope, that some day we will get there, because I see it as one fatal flaw, that could over time kill Emacs. Yes, Emacs as it is is super useful, but more and more things come up, that will be better off running concurrently and in parallel. Just to name a few: Package compilation, waiting for LSP stuff, anything that waits for network, like tramp, running source blocks in org-mode (org-babel), syntax highlighting of big files, magit stuff like rendering huge diffs in a magit status buffer ...
All of those things could benefit from being able to use multiple cores and improve Emacs' snappiness and speed. All of these come before even changing anything about elisp the language.