On Sun, 15 Jun 2025, Ekaitz Zarraga <eka...@elenq.tech> wrote: > Hi Olivier > > On 2025-06-15 16:58, Olivier Dion wrote: >> 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. >> > > Idk, that might help. What it is for sure is that if a project has > enough devs the tooling doesn't matter that much. The current status of > Guile might be bad even with proper tooling.
I would argue that tooling is critical for users adoption. It is the bedrock of a modern language. But in Guile, we lack many things that users might deem important: * A step debugger * Verbose backtrace (no optimized out values) * Missing auto-reloading of modules that depends on a syntax-transformer that was redefined in another module. You can add to that list other irritants like deficient bugs tracker, basically no third-party modules packaged on any distros other than Guix. Irritants like these are enough to prevent users from adopting Guile. Not all of them of course. Now, if you have developers and a vision, you can work to improve the tooling, making a solid foundation that users can rely on, increasing the number of potential contributors for the future [...] >>> 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. [...] > Guile has a very interesting entry point: the standard library. > > All of us are scheme hackers, all of us write scheme code at least for > one project. We could not only contribute to Guile's standard library > but also upstream some of the very interesting tools we have in Guix. I was under the impression that the core of Guile was trying to remain relatively small on purpose, thus the libraries like `guile-lib' and `fibers'. As a side note, Guix code is under GPL and the code in core Guile is LGPL. There might be some friction here. [...] >>> 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. >> > > What do you mean by responsible here? > And by community? Which one Guix or Guile? Or both? Teaching. It's not the job of the developers to teach peoples. There is the documentation for that. But the community is responsible for helping itself. e.g. answering questions on IRC, making blog posts or making a cookbook. Guix is already very good at that I think. Guile's community also, but there is place for improvement. [...] >> [1] https://savannah.gnu.org/bugs/?group=guile > > This is simply very outdated (2011). Yet it is in the top 10 links. It should just be removed from Savannah if it is not meaningful. Thanks, Olivier -- Olivier Dion oldiob.ca
