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.
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.
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).
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.