> Guix is a Linux only solution, and the whole point is not to build anything from 3rd party dependencies.

First, GNU Guix requires a POSIX system, and it will happily run e.g. on top of Debian in a suitable VM. (It will also run as a stand-alone OS which is nice if you want a bootstrapped, totally deterministic system - not good for gaming or casual development yet but there are serious long-term applications for that.)

Also, as said it will build from source only if there is no pre-built binary package available for your platform, otherwise it will use cached binaries. That's, for example, a great use if you need to use cargo with a complex multi-architecture set-up. Just don't forgot to add plenty of disk space - here is a good use for Terabytes-size disks. Further, you can also set up your own build server, which caches binaries.

The decision that it depends on the source code being available is rooted in the philosophy of the project; Guix is a GNU project and is intended to support Free software, as in FLOSS. I think this is also technically a good decision, because if the source code is not available, this leads sooner or later to practically unsolvable problems; think in all the expensive lab equipment in science which runs on decades old, obsolete, unsupported, unsafe platforms just because that expensive hardware requires a binary driver which won't run on more modern platforms. Or think in your scanner that stopped working after the last OS upgrade because the scanner vendor thought you ought buy a new one; that scanner will probably work fine under GNU/Linux, just as an illustration to the point being made.

The need to make software reproducible is especially important in science where the scientific method depends on that experiments, and their evaluation can be repeated, but there is just no budget to port everything to the newest Python3.x, or OpenGL Y, or Qt-Z, or Matlab-ω. Science is competitive, no less than business, and you don't make a career in science with porting old stuff.

But back to "Linux only" - right, there are platforms that Guix will not work on, like Windows. But complaining about that seems, at best, extremely naïve to me: By anyone who has the slightest knowledge in the matter it is well known that these proprietary platforms have literally spent decades on engineering to lock users in into their proprietary solutions. (And I think that the situation especially with C++ is in part a result of that, there is no inevitable technical reason that C++ does not have a standard ABI, or standard library discovery, it was just made that way to stop competitors similar to Borland's Delphi.)

Complaining that their OS (while claiming POSIX compatibility) does not support GNU Guix is justs as, perdon my french, just as silly as complaining that you can't fix the broken battery of your MacBook yourself by taking a screwdriver and replacing it with a standard part. You won't have a screwdriver that fits precisely because the MacBook's vendor thought that you are not supposed to fix it yourself. Of course, the marketing department will tell you that their platform is "compatible to open source" - I have a bridge to sell you.

These systems are just not designed for that, and the inability to use Guix on them is a consequence of your decision to use such a system; you are the one who will pay the costs of that, by having an obsolete scanner, or, far more expensive, by having obsolete, unmaintainable software years from now which is too expensive to port to a new supporting API.