Conda does not solve the problems of deployment and they don't have any reproducibility guarantees. That's not surprising considering how Conda binaries are built.
I use a Guix manifest for every project, which describes what dev tools and dependencies I want. When I enter a directory the shell automatically evaluates the manifest and all my tools are ready.
With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.
I quite like it because it's more predictable than automatic tiling window managers and generally less work than manual tilers. (I've used tilers since maybe 2010 with xmonad.)
I really dislike the cartoons, because they are carelessly generated images. On the first look they appear to be actual cartoons (you know, where details were deliberately placed to convey meaning), but the more you look the more confusing they get because it seems that most details here are accidental.
To me bad illustrations are worse than no illustrations. They also reflect poorly on the author, so I'm much less inclined to give them the benefit of the doubt, and probably end up dismissing their prose.
In all those years working on and playing with free software, I still cannot understand the incessant need for badmouthing other projects and calling things "half-assed". What a destructive habit!
Teenagers have to get up too early. Teenagers experience a shift in their circadian rhythm and also require more sleep than before puberty. School schedules do not account for this shift.
I think stating it this way gets the history backwards. The live bootstrap came about as a separate implementation of what had been done for Guix earlier. It then became a proving ground for new ideas, which then fed back into Guix.
I'm using Guix System on my rockpro64. I patched uboot to allow it to boot via SATA. (One of the patches I needed was to ignore a spurious CPU reset while enumerating SATA devices.)
Humans already have ways to build software on macos, so why bother doing it with something called "Guix" if the thing that we would necessarily --- and for technical reasons --- end up with bears little resemblance to Guix? If someone sees value in that, enough to warrant converting resources to realize this value, they are welcome to do just that.
Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
What is the real reason then? Please enlighten me, because I have been blocked by these technical issues in my past attempts to bring Guix to macOS. Guix is built around glibc and there is no glibc port for macOS. Using XCode for everything is like replacing a bicycle drive train with a steam engine; I guess it's still a vehicle of some sort, but Theseus is still unhappy with his new ship.
Guix has the nonguix channel, which provides the vanilla Linux kernel and other packages that contain blobs or nonfree parts: https://gitlab.com/nonguix/nonguix/
The technical details of the quote are correct, but FWIW I'm no longer working on the GHC bootstrap. It's fun for a while but the lack of interest in the Haskell community and the general high level of ridicule and hostility from the rest of the software world towards all things GNU / free software / bootstrapping have kinda turned me off the whole computer thing.
I've built up to GHC 6 (I've stopped after reaching 6) from GHC 4. GHC 4 does use some generated C files, so it's not a pure bootstrap, but it's still much better than taking a binary of GHC 6 or later.
(I'm the author of the 2017 blog post. I had planned a follow-up but since I didn't have much to show I scrapped it.)