7 ms·

Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general

by dig1 6y ago

Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general optimizations, but with recent work in gccemacs [1] and having complete gcc optimization engine under the belt, can these two be even compared? Also, gccemacs showed you get visible speedups in some use cases only. Have everything under Guile umbrella? Remember, Guile is getting trickier and trickier to build over the years and I don't want that from scripting language whose main idea was to embed it (presumably also ship the source alongside your program in some cases). I'm getting impression even python source & build is easier to ship and you can't go below that. Also, modern Guile compilation time is abysmal. I recently ditched Guix [2] from my system because bootstraping on fairly modern laptop would take hours, mainly because Guile is trying to compile some helper scheme libraries needed for guix to work and recompile everything again with 2-3 different gcc versions (which are bootstraped too). [1] http://akrl.sdf.org/gccemacs.html http://akrl.sdf.org/gccemacs.html [2] https://guix.gnu.org/ https://guix.gnu.org/

eeh 6y ago
Does Guix's remote build caching help avoid every Guix user having to build the full bootstrap? https://guix.gnu.org/manual/en/html_node/Substitutes.html https://guix.gnu.org/manual/en/html_node/Substitutes.html
- davexunit 6y ago
  Yes, I'm not sure why they are doing a full bootstrap. A full bootstrap takes ages for any distro and Guix goes even further than other distros by constantly reducing the size of their binary seed as they work towards a human auditable seed which comes at the expense of increased bootstrapping time.
  - sterlind 6y ago
    At least on nix, I often cache miss the Hydra builds because I'm running unstable. Maybe they set something that's making them bootstrap?
- opan 6y ago
  It's not uncommon to have to build things because you've updated earlier than some others. I remember waiting hours for Rust, webkitgtk, or cataclysm-dda to build on multiple occasions. Sometimes just waiting another day would mean a substitute was available. You could also update your current profile with the exclusion of a few packages, such as the ones that have no substitutes. This is nice, but because it updates your current profile, then you can't remove something you were planning to remove via your package declarations, you're introducing your state then. A temporary issue that gets fixed when you can next apply your package manifest, though.
  - eeh 6y ago
    I can understand why following the master branch can result in massive rebuilds. Does Guix offer a branch that contains code that has been built by the CI builders? In which case, when a user grabs a package they'll be able to grab the compiled version rather than have to compile it themselves.
metroholografix 6y ago
The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potential to destroy Emacs. Emacs Lisp fits the problem domain like a glove. Someone in this thread called it 'the worst Lisp' but that's a mischaracterization. It's actually a good, practical, Lisp and far from the worst. In short, there is enormous value in the current Emacs Lisp ecosystem, and every heavy Emacs user knows it. Guile doesn't really have much to offer, given its terrible performance, lack of interest from developers (and some would say users), platform-compatibility issues and strong potential for diluting a very valuable, very cohesive ecosystem. It is a project that is slowly languishing while Emacs Lisp is slowly but surely getting better.
- teataster 6y ago
  I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I would not change it and it solves the domain problem just fine.
  - metroholografix 6y ago
    There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the core ideas of Lisp as defined through its historical evolution. I also don't see let, letstar, etc as clunky but I've also been using them for more than a decade (and am firmly in the Lisp Machine Lisp -> Common Lisp camp).
    - teataster 6y ago
      You seem to be a more experienced lisper than me (I mostly do elisp scripts and a bit of Clojure) and I have learned a bit from your answer. Thanks.
pmoriarty 6y ago
"what are the benefits of Guile Emacs in 2020 and after?" Here is what Andy Wingo had to say on the subject[1]: Guile can implement Emacs Lisp better than Emacs can. We can compile Emacs Lisp to Guile's VM, and make C shims to present a suitably compatible C interface to the rest of Emacs' C primitives. No one will notice! Except that after a switch, Emacs would be faster, more powerful, and have the ability to access all of Guile's facilities -- the Scheme language, other languages implemented for Guile (Javascript, Lua, ...), a proper ffi, dynamically loadable libraries, a module system, the numeric tower (rationals, bignums, etc), Guile's existing libraries, delimited continuations (!), fast bytevector access, native threads, etc. On a language level, I am convinced that not only can Guile implement Emacs Lisp, but it can provide a coherent story for tight interaction between e.g. minor modes in Javascript and Scheme and Elisp, etc. More details will come later, though feel free to bring up specific points. There have been some suggestions on the list that "Guile people want to rewrite Emacs in Scheme". Though Scheme does have some facilities to offer, personally I do not believe in rewriting software. I've failed enough times, thank-you-very-much -- and if we could retrofit a compiler into Guile in two years via correctness-preserving transformations, surely we can replace the implementation of Elisp without causing problems. My goal is to make it the obvious decision for the Emacs maintainers to say, "yes, let's switch to Guile's implementation of elisp, because it will make Emacs better and have no drawbacks". We're not there yet -- and that's why I wanted to put off this mail -- but we'll get there. [1] - https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...
- metroholografix 6y ago
  I think it's safe to say at this point -more than 10 years later- that Andy Wingo was very optimistic. Absolutely nothing of what he described in that email materialized. And it's no wonder it didn't, since a lot of it is simply wishful thinking. In addition, he didn't address the fact that there are political and not technical reasons behind the absence of certain features (e.g. FFI). They could be done today, without Guile, assuming a consensus on the political front existed. On the other hand, Emacs Lisp has gotten a lot better and not only knocked out some of the features mentioned by Andy (dynamic modules, native threads) but is also making progress towards new directions (GCCEmacs). And as I described in my other comment, I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus. The last thing you do with a cohesive ecosystem like Emacs Lisp's is to introduce needless fragmentation that takes away its core strengths.

by dig1 6y ago

eeh 6y ago

Does Guix's remote build caching help avoid every Guix user having to build the full bootstrap? https://guix.gnu.org/manual/en/html_node/Substitutes.html https://guix.gnu.org/manual/en/html_node/Substitutes.html

davexunit 6y ago
Yes, I'm not sure why they are doing a full bootstrap. A full bootstrap takes ages for any distro and Guix goes even further than other distros by constantly reducing the size of their binary seed as they work towards a human auditable seed which comes at the expense of increased bootstrapping time.
- sterlind 6y ago
  At least on nix, I often cache miss the Hydra builds because I'm running unstable. Maybe they set something that's making them bootstrap?
opan 6y ago
It's not uncommon to have to build things because you've updated earlier than some others. I remember waiting hours for Rust, webkitgtk, or cataclysm-dda to build on multiple occasions. Sometimes just waiting another day would mean a substitute was available. You could also update your current profile with the exclusion of a few packages, such as the ones that have no substitutes. This is nice, but because it updates your current profile, then you can't remove something you were planning to remove via your package declarations, you're introducing your state then. A temporary issue that gets fixed when you can next apply your package manifest, though.
- eeh 6y ago
  I can understand why following the master branch can result in massive rebuilds. Does Guix offer a branch that contains code that has been built by the CI builders? In which case, when a user grabs a package they'll be able to grab the compiled version rather than have to compile it themselves.

metroholografix 6y ago

The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potential to destroy Emacs. Emacs Lisp fits the problem domain like a glove. Someone in this thread called it 'the worst Lisp' but that's a mischaracterization. It's actually a good, practical, Lisp and far from the worst. In short, there is enormous value in the current Emacs Lisp ecosystem, and every heavy Emacs user knows it. Guile doesn't really have much to offer, given its terrible performance, lack of interest from developers (and some would say users), platform-compatibility issues and strong potential for diluting a very valuable, very cohesive ecosystem. It is a project that is slowly languishing while Emacs Lisp is slowly but surely getting better.

teataster 6y ago
I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I would not change it and it solves the domain problem just fine.
- metroholografix 6y ago
  There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the core ideas of Lisp as defined through its historical evolution. I also don't see let, letstar, etc as clunky but I've also been using them for more than a decade (and am firmly in the Lisp Machine Lisp -> Common Lisp camp).
  - teataster 6y ago
    You seem to be a more experienced lisper than me (I mostly do elisp scripts and a bit of Clojure) and I have learned a bit from your answer. Thanks.

pmoriarty 6y ago

"what are the benefits of Guile Emacs in 2020 and after?" Here is what Andy Wingo had to say on the subject[1]: Guile can implement Emacs Lisp better than Emacs can. We can compile Emacs Lisp to Guile's VM, and make C shims to present a suitably compatible C interface to the rest of Emacs' C primitives. No one will notice! Except that after a switch, Emacs would be faster, more powerful, and have the ability to access all of Guile's facilities -- the Scheme language, other languages implemented for Guile (Javascript, Lua, ...), a proper ffi, dynamically loadable libraries, a module system, the numeric tower (rationals, bignums, etc), Guile's existing libraries, delimited continuations (!), fast bytevector access, native threads, etc. On a language level, I am convinced that not only can Guile implement Emacs Lisp, but it can provide a coherent story for tight interaction between e.g. minor modes in Javascript and Scheme and Elisp, etc. More details will come later, though feel free to bring up specific points. There have been some suggestions on the list that "Guile people want to rewrite Emacs in Scheme". Though Scheme does have some facilities to offer, personally I do not believe in rewriting software. I've failed enough times, thank-you-very-much -- and if we could retrofit a compiler into Guile in two years via correctness-preserving transformations, surely we can replace the implementation of Elisp without causing problems. My goal is to make it the obvious decision for the Emacs maintainers to say, "yes, let's switch to Guile's implementation of elisp, because it will make Emacs better and have no drawbacks". We're not there yet -- and that's why I wanted to put off this mail -- but we'll get there. [1] - https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

metroholografix 6y ago
I think it's safe to say at this point -more than 10 years later- that Andy Wingo was very optimistic. Absolutely nothing of what he described in that email materialized. And it's no wonder it didn't, since a lot of it is simply wishful thinking. In addition, he didn't address the fact that there are political and not technical reasons behind the absence of certain features (e.g. FFI). They could be done today, without Guile, assuming a consensus on the political front existed. On the other hand, Emacs Lisp has gotten a lot better and not only knocked out some of the features mentioned by Andy (dynamic modules, native threads) but is also making progress towards new directions (GCCEmacs). And as I described in my other comment, I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus. The last thing you do with a cohesive ecosystem like Emacs Lisp's is to introduce needless fragmentation that takes away its core strengths.