At this point we'd be better off with the GP chiming in, what I was responding to was "after running into problems with the number of Guile dependencies". So n

At this point we'd be better off with the GP chiming in, what I was responding to was "after running into problems with the number of Guile dependencies". 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.