3 ms·
Hrm. I don't know if I agree with this or not. Your last sentence is 100% spot on. But at the same time, I've used Emacs as a window manager before, and the rea
by danShumway 3y ago
Hrm. I don't know if I agree with this or not. Your last sentence is 100% spot on. But at the same time, I've used Emacs as a window manager before, and the reason I stopped was because of IO blocking the UI. I could not handle having a process bug out and having it freeze my entire window manager, and it happened frequently.
I don't want to dismiss the argument; maybe it's just that Emacs packages are bad at avoiding that behavior? But I'm not sure that async I/O primitives are enough for a text editor, even though I would generally agree with you.
On the subject of that last sentence:
> A lot of the I/O blocking UI problems could be alleviated by just moving to async I/O primitives without incurring the runtime and developer experience problems of a multi process architecture
This sounds like an advertisement for Javascript to me? This is one of the reasons I think why NodeJS became so popular when it was first introduced, literally because it was single-threaded with good async I/O primitives (or good enough, this was before Promises were in the language), and that led to huge performance improvements over other server implementations that prioritized workers.
So while I still don't like the kitchen sink approach, I'm still left feeling like a lot of the problems and solutions being proposed here are kind of things that would be addressed by using Deno in Emacs? At least, I'm seeing the appeal. Single-threaded memory pool to help make developer experience better and to improve performance, coupled with decent async I/O primitives -- that's Javascript, that's one of the things the language is sort of good at. You have workers for larger tasks, and that's definitely handy, but most of your programming is happening in a single-threaded event loop using promises.
If I looked at this sentence in isolation, I would think that you were arguing in favor of adding Deno.
- samus 3y agoAdding a new language still doesn't solve the blocking problems with the current extensions. It still seems way less complicated to just patch the extensions that are not behaving well. If their maintainers don't want to cooperate, there is always the possibility to fork these extensions, but that's also way easier than writing these from scratch or treating them in Typescript.
- danShumway 3y ago> Adding a new language still doesn't solve the blocking problems with the current extensions. That is a pretty strong argument which I agree with. The somewhat dismissive answer I could give around JS in Emacs is that if I wanted to write JS so badly that I was willing to rewrite the ecosystem in order to do it, I'm not sure why I shouldn't just use VS Code. I'm floating the idea that JS would be a good fit for a lot of these problems, but it is correct to ground that with the idea that having 2 separate coding languages in a text editor just feels weird and cumbersome and I don't know, isn't the ecosystem fragmented enough? I can't actually avoid Elisp in Emacs and I wouldn't be able to just because Javascript was added.