On Sun, 15 Jun 2025, Ekaitz Zarraga <eka...@elenq.tech> wrote: > Hi, > > I’ve been talking a lot recently, and not that recently, with many of > you about the status of Guile and about the fact that we, Guix users and > developers, rely on it for most of our computing. > > Most of us would probably agree on that we should give Guile a little > bit more of love. > > There is a problem, though, that I’ll try to describe from my experience. > > I’ve been trying to improve Guile for long but all the very small > patches I’ve been sending during the last years haven’t been > reviewed[^1]. While larger patch sets have only been reviewed and > accepted, basically, because the maintainers know me and I have been > pinging them repeatedly (thank you <3).
I think that the patches workflow might be a problem here. I don't mind it personally, but I think that patches do get lost in inboxes. Furthermore, the discoverability of known bugs is more difficult that way, I believe. For example, there is an open bug that srfi-37 (args-fold) segfaults the program under certain cases. I know a workaround for that bug that can be used today without fixing Guile. But a newcomer might not find that bug report that quickly or ever. I know that Guix has decided to move to CodeBerg. Maybe Guile could do the same. [...] > From my experience, it feels like while the maintainers are great > programmers and are able to deliver great software for us, are too busy, > to the point that it feels like a exception to see someone’s patch > accepted by them. In Andy’s case this problem might be even worse, > because he’s the only maintainer of Lightening, and probably he’s the > person in the planet that knows more about how Guile and programming > languages, in general, work. > > There are committers in Guile, too, and they are also doing a great > work, but my feeling is there are not enough of them, at least to > accommodate the potential increase of contributions that I’d like the > project to have, because they are already struggling. > > I’m not criticizing, quite the contrary: I think they need help, so they > can do what they do with more freedom and joy. I concur. > There’s also a second problem, but I think that’s the easiest one to > solve. I’ve been working with compilers and programming languages for > the last couple of years and most of my programmer friends talk to me as > if I was crazy. I see why that is, because I can recognize the feeling. > Not that long ago, I was also scared of languages. > > We tend to look to the long term probably way more than other projects > do, that’s why we pay attention to bootstrappability, reproducible > builds and so on, and I think we have the energy and the people to > tackle an extra front: the language. > > Hacking on a programming language is as easy as any other program, but > also as difficult. Programming languages, specially scheme > implementations, have quite a bit of background and scientific research > on their past. Understanding the subject takes time and study and, in my > opinion, the best way to learn is from others. Sadly, Guile is not as > active as a community as Guix is, where people share their knowledge and > encourage newcomers to make packages, improve their configuration and > so on. The thing is that Guix has a natural entrypoint for contribution, e.g. packaging something trivial. Then you can learn packaging more difficult things by changing arguments, phases, applying patches, making a new build system type, etc. Then I guess you can start contributing to core things. In my personal experience, I've looked at the bugs in Guile [0-1] (these at the top results I get when searching "guile bugs"). Now, I want to help. Where do I even start? I dig the bug-guile archive? Probably not. I look through bugs on Savannah that started from 2006 and end in 2011? There is no discoverability to see what needs to be done to improve the language. When I did contributed was when I got a bug while working on my projects. > I believe we should get more involved in Guile, not only because Guix > relies on it but also because we should know more about how it works. > This knowledge should be more accessible and commonplace, not just > something that only a few programmers know. I fear that the internal knowledge of Guile get lost at some point. I don't like bringing this up, but is there consideration for the bus factor? Knowledges need to be transmitted or are doomed to be lost. > We could and should teach each other. There was an idea couple of years back to make a Guile Cookbook. Might be a very good starting points instead of the sparsed blog posts we have. > But we shouldn’t put more responsibility on those that already are doing > more than their best: the Guile developers. I think this should be > bootstrapped one way or another, so we can help them relief some of the > weight they are struggling to lift. I think that the community is responsible for that. [...] [0] https://lists.gnu.org/archive/html/bug-guile/ [1] https://savannah.gnu.org/bugs/?group=guile Thanks, Olivier -- Olivier Dion oldiob.ca
