emacs

ies can't keep up with it. Architecturally it is kind of insane. I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness. https://github.com/emacs-lsp/emacs https://github.com/manateelazycat/lsp-bridge

you need a bit of plumbing to get the results back, but it's possible. I found this: https://github.com/emacs-lsp/emacs/blob/json-rpc/src/json.c very interesting: it's a fork that moves JSONRPC from Lisp to C and out of the main thread. See for example line 1109 and related. > but threads are pretty useful already if hard to code with. That's the point: the capabilities are there (mostly), but abstractions are not. Coding with threads, even in the presence of the global lock, is hard, and ensuring correctness is nontrivial. At the very least we should get channels for communication (share by communicating, don't communicate by sharing) between threads and thread pools for executing tasks (like futures in Java or Python, or Task in Elixir). Threads and locks are way too low-level for normal coding. I suspect that's the reason why they're not used more widely, even though they're there for the third(?) release now. Aside: Racket is actually a nice example of concurrency and parallelism being treated as completely separate concerns. IIRC threads in Racket are call/cc-based green threads, while places are separate instances of the VM that execute in OS-level thread or separate process. Threads provide concurrency and places provide parallelism. It's actually a good thing, I think. Mixing the two is often a major source of errors. Racket also has futures, which are parallel-if-possible primitives that can benefit from parallelism if they don't touch external state - a sort of a middle ground. In any case: yes, Elisp threads are a good addition to the language, but they alone are not enough to bring concurrency to the masses, so to speak. As a concurrency primitives, and compared to callbacks, they have few advantages and some serious downsides. Emacs still needs a lot of work on the concurrency front. And don't even mention parallelism, that's another can of worms that we don't really need to open :)