GNU Guile v2.9.2 – an embeddable REPL for scripting your GUI
lists.gnu.org
lists.gnu.org
Guile's list of mandatory dependencies is short, and consists of libraries like libgmp (also used by GCC), libiconv etc., I doubt a packager would have much issue with the stability of those. These are libraries that work on dozens of platforms across a wide range of compiler versions: http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20
More generally the trade-off with libraries cuts both ways, and I've seen other programmers underestimate the maintenance burden of rolling their own v.s. the investment in just including a well-tested third-party library. E.g. it's very common for C programs to have their own buggy and often insecure version of something like a string library, DNS resolver etc.
That's not free for you as a user of those programs either. E.g. the other day I was dealing dealing with an issue in how bitlbee resolves SRV records with its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.
> they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application.
...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above).
Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals.
This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks.
> its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.
Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.
So not the stability of the dependencies, or any specific issue with them, just the number of them.
In practice I've encountered a lot of cases where C programmers in particular tend to get what's best described as dependency vertigo resulting in badly re-inventing the wheel.
I'd be much more confident in using Guile with its 10 dependencies (or thereabouts) than some random similarly-sized C program.
Something the size of Lua or Guile isn't someone's weekend project. No matter what other people have a say in the direction of your program. I'd argue that you're generally better off structuring it in such a way as to make use of already-invented wheels, and users are better off not shying away from dependencies.
We're not talking about something like the absurd 100-line dependencies node.js has made famous, but whether a compiler like Lua needs to implement its own bignum handling (or as it at all), v.s. Guile doing the same via libgmp, and thus sharing bignum behavior with something as well-tested as GCC.
If you're a Guile core developer would you rather e.g. deal with guile's home-grown text encoding library or iconv? I know which one I'd pick both as a developer & user.
I'm coming round to the suckless philosophy personally though.