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.
Also, as I suggested, pushing for a infrastructure change in a project
has organizational problems and we are not part of is kind of an
overreach. I don't know if that could be a good short/mid term solution.
Ludovic, who pushed for a migration in Guix is one of the Guile
maintainers, so we might see it happen, but I don't feel comfortable
proposing that from the outside, even if I mostly agree with you.
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.
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.
Guile's standard library is as easy to read as Guix's code. That is a
great starting point for going forward for more.
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.
This was the trigger for the email, precisely.
I'm working in GNU Mes right now, and I go and research in Guile to
learn about how things are done in a powerful scheme implementation. I
wish I could have a (maybe virtual) coffee with those who implemented
Guile's internals and ask them about this and that. I think that
knowledge nowadays is very concentrated in Andy, and the JIT library is
a paradigmatic example of it: its published in his personal gitlab account.
A similar thing happens with guile-fibers.
We are very lucky to have a such a great language hacker in Guile but
I'm afraid of (slowly or dramatically) losing all that knowledge and
also the potential improvements it could bring us.
In practice, we are already in that situation Guile's core doesn't
change much these days. This might be because Guile is already perfect
or because there's not enough people that have the skills to touch it.
NOTE: One might argue that Whippet is a significant change in Guile's
core, and it is, but it represents more the "developer" role than the
"maintainer" role of Andy, who, btw, has publicly stated he likes to
write software, but not to maintain it.
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?
[0] https://lists.gnu.org/archive/html/bug-guile/
As I was writing this answer I opened some of these bugs. Most of them
have 0 replies.
[1] https://savannah.gnu.org/bugs/?group=guile
This is simply very outdated (2011).
Thanks,
Olivier
Thanks for taking part in the discussion,
Ekaitz
