emacs is a lot faster now that it uses a JIT elisp compiler by default. I don’t really think switching to a different runtime will make much of a difference there.

this is my concern as well, i think vim wins for a lot of folks because of latency and that an emacs successor should prioritize performance and low ux-interruptions in it's values and culture. fwiw, i'm much more comfortable optimizing atop guile's bytecode than elisp.

I cannot speak to nice graphics (I don't want a different way to represent directory trees or git branches, I'm happy with how it's done today), but on the count of Magit's speed... it's not really the problem of the language. It's the problem of how the program is written. Well, maybe in a way it is also the language. With some languages you have more room to be sloppy, with Emacs Lisp, when used in this way, you have to be very careful.

In my experience with Magit, the slowness usually comes from a large number of subprocess calls that are made to render some aggregated piece of information. Eg. some table that has a bunch of commit hashes, but then the way it's rendered, the hashes are links that need to have, as part of the link, some information embedded in them that's only available through a separate subprocess call, one per commit hash... Emacs Lisp obviously adds some overhead, but the larger problem is the need to make these dozens of subprocess calls.

I don't think there's an immediate solution to this problem though. Most likely, in specific cases where this amplification of subprocess calls Tartius (or whoever mans the project today) needs to rethink the buffer layout, make things load lazily, maybe add some caching... but this isn't going to happen quickly. On the bright side, these changes do happen every now and then. In the end of the day, I use Magit almost exclusively today, I even have my extensions to Magit (specifically for Git grep command), and I wouldn't trade it for any other Git interface. I wish it was better, but I haven't found anything that would've been better in practical terms.

Does this mean rewriting Magit to use libgit2 FFI bindings[0] rather than subprocess calls would lead to significant speedups?

[0]: https://github.com/emacsorphanage/libegit2

Maybe, but I wouldn't hold my breath. It's more about how much data needs to be fetched and how many calls have to be made to fetch it. With Maigt, it sometimes feel like a select-in-loop anti-pattern. I.e. Git only exposes information in certain slices from its database. It's hard to run free-form queries on it. Often, Magit wants to display something that cannot be phrased as a single query, so it needs to do multiple. These queries also cannot be made concurrently, or even if they could be, the concurrency overhead would've been too much.

So, using the library will remove the overhead of exec() and friends, and will definitely make the situation better, but the ultimate solution is either for Git to be more like SQL database, or for Magit to extract information directly from the Git database, rather than go through the API (but the choice of Emacs Lisp for this functionality would be highly questionable).

Actually, if it has true support for async and better graphics, the UI can be modified so it is "perceived" to have better speed. In the current Emacs, some actions are slowe and we know it has nothing to do with Emacs as they depends on external processes. But it makes entire Emacs hang, and it's terrible from user perspective. If there is a way to make those operations running async, with some nice text messages/graphics to indicate the status, it would be much better. It is similar to the story about installing mirrors inside elevators and made people feel waiting time is much shorter, while travelling time was actually the same.

Previous attempts at guile-emacs weren't faster: fixing the impedance mismatch between elisp and guile ate all the speedup that guile would bring.

Also as a significant change since the last attempt, elisp got a proper native compiler.

That's not really accurate. The previous attempt proved that it worked, but we all know that getting something working and making something performant are two different things. If there were some buy-in to this initiative, the performance issues of the "MVP" can be addressed. Guile also advanced its compiler during the same time, gaining more optimizations and a JIT compiler.