No new commits yet, just a talk about a future relaunch. Only strings performance is missing.
Gypsum https://emacsconf.org/2024/talks/gypsum/ started from guile-emacs afresh, but is way behind.
And with Andrea's elispjit the guile port is probably not needed at all.
> And with Andrea's elispjit the guile port is probably not needed at all.
Performance aside, there's more to Guile Emacs: possibility of true concurrency, incremental garbage collection, cleaner separation of the interpreter and UI components, better maintained in the long run...
It would allow using any language that runs on the Guile VM. Guile has a compiler tower model where you define languages and their path towards being lowered to bytecode. The main language, Scheme, lowers to the Tree-IL language (high-level intermediate representation), then to the CPS language (low-level IR), and finally to bytecode. Elisp lowers to Tree-IL, which means from there it takes the same path as Scheme does to reach bytecode, so it gets to benefit from all the performance optimizations happening in Tree-IL (like partial evaluation) and CPS (which are numerous, like common subexpression elimination, contification, dead code elimination, etc.) It's a pretty neat system where all these different languages can intermingle in a pleasing way.
My understanding is that this is very far from being usable. But I mention it here because I suspect that some people on HN would be interested in the possibility of eventually running JS inside of Emacs.
I wish Robin luck in relaunching the guile-emacs project! I hope that this talk will help the Emacs community understand the potential and be more open to the prospect this time around.
i have one question, for me emacs have only 1 major flaw (or you can call it drawback) , its slow, some extensions are very very slow , magit for me is the prime example , json-navigator is another
will this make emacs fast , i understand guile is a nicer language than elisp, but if its not significantly faster, this i think will go nowhere
(the second but minor flaw, it need better graphics, nicer ways to represent directory trees or git branches, other than ascii, but if emacs becomes fast, i can live with that)
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.
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).
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.
One of those "Never Ever" projects. The idea appeals to me, but most of the emacs user community seems uninterested so I don't think it will ever succeed. Nonetheless, Godspeed.
In a kind of tragic irony of sorts, we now have VSCode (Electron based, similar in resource consumption as when Emacs was new, hence the "eight megabytes and constantly swapping" joke), using JavaScript as extension language, which was supposed to be originally based on Scheme.
VSCode is very different from Emacs in terms of philosophy. VSCode is notepad with extensions bolted on (like every other common editors). Emacs defines a more purposeful environment for working with text. And that is why you can get features like Compilation Mode, Occur Mode, systems like Org-Mode, and whole applications like magit, ebib, emms.
As someone that favoured XEmacs instead, I am well aware of the philosophy, and also why very few of newer generations even bother, as shown on its userbase share nowadays as per developer surveys.
It’s a community project, increasing userbase should not be a priority concern. Though it should be user-friendly (emacs is as long as the user RTFM), I believe going for the common denominator instead of solving the community’s problem efficiently is less pragmatic. Before VSCode there were many, and there will be many afterwards.
And VSCode is still strongly reliant on Microsoft’s resources.
i am not user of emacs, but looking into as next switch.
using mainstream more structured language is good point go into emacs.
it also will lead to rewrite of some plugins. for example many rust rewrites just better c versions, but more consistent and structured. there was not reason not to rewrite these in c but better. very good for newcomers to unix world.
another point is async. i have heard that is one of problems of no async. if emacs has plan it could be intresting either doing async or properly avoiding. for me it is prove point emacs will not die with its creators.
There are code bases for SINGLE Lisp applications which go into several million lines of code. For example PTC's CAD system had several years ago >7 million lines of Common Lisp.
Between this and things like Guix and Hoot, sometimes I feel like I could find incredible peace and happiness if I just sold all my possessions and moved into the Guile monestary, so to speak.
I really wish folks building these things in Scheme would build them instead in Lisp. Common Lisp is a better language for systems, despite a few design decisions which turn out to have been howling mistakes (the single worst is the default reader upcasing).
Wow that's some high praise. For anyone wondering, Hoot is a Scheme to WebAssembly compiler that is really cool (and also I'm one of the devs and also I don't live in a monastery.)
I'm just a lurker but ty guys so much, doing really exciting things imo! As I waste away a little in VC startup world, yall are one of the handful of things that give me hope with all this computer/internet stuff we are working on all the time.
I worked at regular software companies for quite some time before Spritely, so no judgement here. I hope you can get the sort of job that is fulfilling to you, though! I'm glad we can give you some hope. :)
No new commits yet, just a talk about a future relaunch. Only strings performance is missing.
Gypsum https://emacsconf.org/2024/talks/gypsum/ started from guile-emacs afresh, but is way behind. And with Andrea's elispjit the guile port is probably not needed at all.
> And with Andrea's elispjit the guile port is probably not needed at all.
Performance aside, there's more to Guile Emacs: possibility of true concurrency, incremental garbage collection, cleaner separation of the interpreter and UI components, better maintained in the long run...
I'd also highlight the work that's being done here:
https://codeberg.org/lyrra/guilemacs
> integrates Emacs and Guile by providing a new Elisp implementation based on Guile's Lisp-oriented compiler tower and runtime environment
I am hoping Guile the language (scheme) also will be supported alongside elisp.
It would allow using any language that runs on the Guile VM. Guile has a compiler tower model where you define languages and their path towards being lowered to bytecode. The main language, Scheme, lowers to the Tree-IL language (high-level intermediate representation), then to the CPS language (low-level IR), and finally to bytecode. Elisp lowers to Tree-IL, which means from there it takes the same path as Scheme does to reach bytecode, so it gets to benefit from all the performance optimizations happening in Tree-IL (like partial evaluation) and CPS (which are numerous, like common subexpression elimination, contification, dead code elimination, etc.) It's a pretty neat system where all these different languages can intermingle in a pleasing way.
I know there was incomplete work done at some point on implementing JS for Guile: https://www.gnu.org/software/guile/manual/html_node/ECMAScri...
My understanding is that this is very far from being usable. But I mention it here because I suspect that some people on HN would be interested in the possibility of eventually running JS inside of Emacs.
I wish Robin luck in relaunching the guile-emacs project! I hope that this talk will help the Emacs community understand the potential and be more open to the prospect this time around.
i have one question, for me emacs have only 1 major flaw (or you can call it drawback) , its slow, some extensions are very very slow , magit for me is the prime example , json-navigator is another
will this make emacs fast , i understand guile is a nicer language than elisp, but if its not significantly faster, this i think will go nowhere
(the second but minor flaw, it need better graphics, nicer ways to represent directory trees or git branches, other than ascii, but if emacs becomes fast, i can live with that)
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).
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.
One of those "Never Ever" projects. The idea appeals to me, but most of the emacs user community seems uninterested so I don't think it will ever succeed. Nonetheless, Godspeed.
In a kind of tragic irony of sorts, we now have VSCode (Electron based, similar in resource consumption as when Emacs was new, hence the "eight megabytes and constantly swapping" joke), using JavaScript as extension language, which was supposed to be originally based on Scheme.
VSCode is very different from Emacs in terms of philosophy. VSCode is notepad with extensions bolted on (like every other common editors). Emacs defines a more purposeful environment for working with text. And that is why you can get features like Compilation Mode, Occur Mode, systems like Org-Mode, and whole applications like magit, ebib, emms.
As someone that favoured XEmacs instead, I am well aware of the philosophy, and also why very few of newer generations even bother, as shown on its userbase share nowadays as per developer surveys.
It’s a community project, increasing userbase should not be a priority concern. Though it should be user-friendly (emacs is as long as the user RTFM), I believe going for the common denominator instead of solving the community’s problem efficiently is less pragmatic. Before VSCode there were many, and there will be many afterwards.
And VSCode is still strongly reliant on Microsoft’s resources.
A project with dwindling community is certainly a concern.
VSCode isn't the only option, indeed.
i am not user of emacs, but looking into as next switch.
using mainstream more structured language is good point go into emacs.
it also will lead to rewrite of some plugins. for example many rust rewrites just better c versions, but more consistent and structured. there was not reason not to rewrite these in c but better. very good for newcomers to unix world.
another point is async. i have heard that is one of problems of no async. if emacs has plan it could be intresting either doing async or properly avoiding. for me it is prove point emacs will not die with its creators.
> using mainstream more structured language is good point go into emacs.
Are you really trying to tell use that Guile Scheme is more mainstream than Emacs Lisp?
Cmon, I'm pretty sure all schemes combined don't have a fraction of programmers or libraries as elisp alone.
I never really thought about this angle, but it’s still worth pointing out that elisp is not used outside of emacs, while other lispen are.
Possibly all lisp combined!
There are code bases for SINGLE Lisp applications which go into several million lines of code. For example PTC's CAD system had several years ago >7 million lines of Common Lisp.
Between this and things like Guix and Hoot, sometimes I feel like I could find incredible peace and happiness if I just sold all my possessions and moved into the Guile monestary, so to speak.
I really wish folks building these things in Scheme would build them instead in Lisp. Common Lisp is a better language for systems, despite a few design decisions which turn out to have been howling mistakes (the single worst is the default reader upcasing).
Wow that's some high praise. For anyone wondering, Hoot is a Scheme to WebAssembly compiler that is really cool (and also I'm one of the devs and also I don't live in a monastery.)
https://spritely.institute/hoot/
I'm just a lurker but ty guys so much, doing really exciting things imo! As I waste away a little in VC startup world, yall are one of the handful of things that give me hope with all this computer/internet stuff we are working on all the time.
I worked at regular software companies for quite some time before Spritely, so no judgement here. I hope you can get the sort of job that is fulfilling to you, though! I'm glad we can give you some hope. :)
very important line of work