- Building takes space, but the build takes place in a temporary directory that is discarded afterwards, and only the output artifacts are kept.

- ~Normal software is usually served pre-built from a cache, which short-circuits the above as long as the package is available from the cache.

- One of the nicer things about the process Nix uses here is that it's also tracking what's ~in-use (via "GC roots"), and you can trivially garbage-collect everything in /nix/store that isn't.

- On macOS I use Nix for just about everything that isn't a desktop app. My /nix mount had 9.7G used when you asked this question, and 3.6G after I garbage-collected, and 7.1G after I re-built the dev environment for a server project.

- The ~3.4G I mentioned above is a really big fraction of my total, but as a reference point, Nix is natively replacing, in ~3.4G, the Vagrant/virtualbox VM I used to need for this development.

- In my experience, the only time I'd describe the storage load as "a lot" is when I've been iterating on something that is fairly large. This can add up as the store accumulates slightly-different copies, but these can be readily GCed.

- Multiple versions of something (say, multiple different pythons or rubies or llvms) will consume more space, but the ~Nix way also makes it possible to avoid vendoring. At system scale I would _guess_ these are a wash?

- At least when you're using Nixpkgs, "multiple versions" generally just means a few major/minor version variants of common dependencies (i.e., at a single commit, most things in Nixpkgs that use Python 3.7 reference the same build).

Anyway I wanted to also to make comment to GPs explanation. What is written, is how Nix is currently addressing each package (it's a hash computed based on source code, dependencies, system, compile options etc).

In many cases different options or change in source files can still produce the same exact package, but under a new hash. Nix has an optimise-store command that scans its store and if two packages have exact same result it uses hard links. That similarly can be run via schedule. This ensures that duplicates do not occupy extra space.

Though in context of nix, what is referred as content addressed is the new way Nix planning to address the package. Instead of computing hash from package and its dependencies it computes hash based on the package's contents. That solves many problems with the old way, but of course question is how is it done, because it kind of is impossible to get hash of something that you did not produce yet. Of course like everything of this kind, it's possible to do if you cheat a bit. Package is first compiled with a dummy paths, then hashed, then references to those paths are substituted.

Here's more about [1].

Having said that, in the blog article when they use "content addressable" it looks like they still meant the current way of doing it (it looks like proper term is input-addressable), not the new way, but if you search "nix content addressable" you are likely find articles about the new way and things might get confusing.

[1] https://www.tweag.io/blog/2020-09-10-nix-cas/

Also played a bit with the Glitch import on an Elm import but found it broke npm in weird ways (something about a file being moved but not found?), but then the Github import of the same project wouldn't work either because of Node version incompatibilities that don't seem to be repl.it's fault exactly other than just "it runs node 12 and some stuff is broke on node 12".

Does look promising otherwise though, with the Nix support I can see soooo many things being possible that simply weren't on other similar options like this.

For a company that prides itself in customer service, I don't see any other way but to run their own email exchange (ala Amazon) because their private systems can then discern between email-ids of paying customers and spam, if nothing else.

In my experience, any ticketing system will be a huge improvement over using a shared gmail inbox for support.