Comment by taylanub | Hacker News Reader

Comment by taylanub | Hacker News Reader

Parent Full thread

From my understanding, the biggest disadvantage to purely functional package management is that you can't just swap out a package in isolation when many others depend on it. If I upgrade a package, I have to upgrade its whole DAG of dependent packages if I want them to use the new version (I could however delay that; they would simply continue to use the old version which hasn't been garbage-collected yet because they still use it).

So lots and lots of compilation (on build farms at least), and lots of bandwidth usage. Though something like ccache can help with the compilation, and binary diffs could help with the bandwidth.

Immutable data structures in FP are probably a good analogy.

Edit: argh, this was supposed to be a reply to the question about the disadvantages of the purely functional package managers specifically, not the OS in general.

To save compilation time and bandwidth the authors might be able to make their package dependencies sort of inside out, using a smaller program simply to perform the needed library loading and dependency injection on the core of the software.

Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change.

    jabberwork-1.2
      jabberwock.core-1.6
      jabberwock.apache.interface-0.3
    
    jabberwock-1.3
      jabberwock.core-1.6
      jabberwock.apache-interface-0.4

Instead of having to update all the hefty ".core" modules, you could get away with only updating the hopefully lighter launchers / library loaders and the specific interface code being updated.

I also started thinking things along the lines of that when I first looked into how Guix does things, but after annoying the developers a little (many thanks to Ludovic's patience) I've come to understand that things like that beat the whole purpose of having pure packages not only in binary content but also in run-time behavior.

Basically, reproducible builds are a red herring here. A package's identity is not only the hash of its byte-by-byte contents, it also includes ("closes over") the identities of all packages it "references" (depends on), meaning it will always have the exact same run-time behavior everywhere because even all its dependencies count as part of its identity.

Reply on news.ycombinator.com