5 ms·

Well, one of the major points of Guile (speed) is becoming obsolete as people are working in native-compiling elisp with libgccjit[0]. It provides great speed b

Well, one of the major points of Guile (speed) is becoming obsolete as people are working in native-compiling elisp with libgccjit[0]. It provides great speed benefits: an average of x3~4 and up to ~x20 on recursive functions. With type annotations we can speed it up more — no need for a Guile JIT for speed anymore. [0]: https://akrl.sdf.org/gccemacs.html https://akrl.sdf.org/gccemacs.html

davexunit 6y ago
Guile-Emacs was making a larger point about GNU: What if instead of each application being its own island, there was more of a shared infrastructure? A text editor (or any other GNU application) shouldn't have to concern itself with programming language implementation, they should be able to focus on their problem domain. GNU devs could use Guile as a solid base for user-extensible programs (something GNU as a whole is supposed to value, but in practice mostly doesn't except for Emacs and a few others.) I don't think this will ever happen because GNU lacks cohesive vision and leadership, but Guile-Emacs was a worthy experiment anyway. There is one success story in GNU, though: Guix. That project has demonstrated the mutually beneficial relationship that other GNU projects could have with Guile if they ever wanted to go that route.
pzone 6y ago
This project looks very promising!
eklitzke 6y ago
I came here to post this as well. I've been running the feature/native-comp branch as my main Emacs and it's really impressive. I'm not sure when it will be ready for consideration for merging (there's still a lot of active development) but this branch is definitely the future of Emacs.
jjdredd 6y ago
Integrating a compiler into a text editor to speed it up is a bit of an overkill imo. What if a lisp source changes and needs to be recompiled? What if several lisp files change? Does it mean that it also needs a sort of a build system? This brings the joke about an "operating system that lacks a decent editor" closer to reality (or reality closer to the joke).

davexunit 6y ago

Guile-Emacs was making a larger point about GNU: What if instead of each application being its own island, there was more of a shared infrastructure? A text editor (or any other GNU application) shouldn't have to concern itself with programming language implementation, they should be able to focus on their problem domain. GNU devs could use Guile as a solid base for user-extensible programs (something GNU as a whole is supposed to value, but in practice mostly doesn't except for Emacs and a few others.) I don't think this will ever happen because GNU lacks cohesive vision and leadership, but Guile-Emacs was a worthy experiment anyway. There is one success story in GNU, though: Guix. That project has demonstrated the mutually beneficial relationship that other GNU projects could have with Guile if they ever wanted to go that route.

pzone 6y ago

This project looks very promising!

eklitzke 6y ago

I came here to post this as well. I've been running the feature/native-comp branch as my main Emacs and it's really impressive. I'm not sure when it will be ready for consideration for merging (there's still a lot of active development) but this branch is definitely the future of Emacs.

jjdredd 6y ago

Integrating a compiler into a text editor to speed it up is a bit of an overkill imo. What if a lisp source changes and needs to be recompiled? What if several lisp files change? Does it mean that it also needs a sort of a build system? This brings the joke about an "operating system that lacks a decent editor" closer to reality (or reality closer to the joke).