Programming Language Domain</th>	Deployment Domain</th></tr></thead>
memory</td>	disk</td></tr>
value, object</td>	file</td></tr>
address</td>	path name</td></tr>
pointer dereference</td>	file access</td></tr>
pointer arithmetic</td>	string operations</td></tr>
dangling pointer</td>	path to absent file</td></tr>
object graph</td>	dependency graph</td></tr>
calling constructed object with reference to other object</td>	runtime dependency</td></tr>
calling constructor with reference to other object, not stored</td>	build-time dependency</td></tr>
calling constructor with reference to other object, stored</td>	retained dependency</td></tr>
languages without pointer discipline (e.g. assembler)</td>	typical Unix-style deployment</td></tr>
languages with enough pointer discipline to support conservative garbage collection (e.g. C, C++)</td>	Nix</td></tr>
languages with full pointer discipline (e.g. Java, Haskell)</td>	as-yet unknown deployment style not enabled by contemporary operating systems</td></tr> </tbody></table> This model suggests viewing the file system as memory and package management as memory management. That reshapes how we can think about software deployment.</p> Isolation and Reliable Identification</h2> One of the challenge in package management is avoiding file path collisions. When multiple packages want to install files to the same location, conflicts arise. Traditional approaches have limitations:</p> Using component name and version alone isn't sufficient (what about different build options?)</li> Random allocation would be inefficient and generate duplicates</li> </ul> The Hash Solution</h2> Nix's approach is to compute a cryptographic hash of all inputs that affect a package, including:</p> The sources</strong> of the components</li> The build script</strong> that performed the build</li> Any arguments or environment variables</strong> passed to the build script</li> All build time dependencies</strong>, including compilers, linkers, libraries, standard Unix tools, shells, etc.</li> </ul> This hash becomes part of the path where the package is stored, ensuring that different versions or builds of the same package can coexist without conflicts.</p> The Nix Store</h2> The cornerstone of Nix is the /nix/store</strong> directory, where all packages are stored using their unique hash identifiers. For example:</p> ~</span></span></span></span> ❯ which wget</span> </span>/nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4/bin/wget</span></span> </span> </span>~</span></span></span></span> ❯ ldd /nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4/bin/wget</span> </span>libpcre.so.1</span></span> =></span> /nix/store/pxl4n1lrns2xhc8f1s04srb4cphlg5cz-pcre-8.45/lib/libpcre.so.1</span> </span>libuuid.so.1</span></span> =></span> /nix/store/y5975fancsig22f6xw22mmmffn19n8zp-util-linux-minimal-2.39-lib/lib/libuuid.so.1</span> </span>libidn2.so.0</span></span> =></span> /nix/store/vh4pdds47783g12fmywazdx3v3kx0j4x-libidn2-2.3.4/lib/libidn2.so.0</span> </span>libssl.so.3</span></span> =></span> /nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9/lib/libssl.so.3</span> </span>libcrypto.so.3</span></span> =></span> /nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9/lib/libcrypto.so.3</span> </span>libz.so.1</span></span> =></span> /nix/store/mgz7sp9jxnk7c3rn1hvich9n0k2rjr7m-zlib-1.2.13/lib/libz.so.1</span> </span>libc.so.6</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libc.so.6</span> </span>libunistring.so.5</span></span> =></span> /nix/store/aw137ya6rvy61zw8ydsz22xwarsr8ynf-libunistring-1.1/lib/libunistring.so.5</span> </span>libdl.so.2</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libdl.so.2</span> </span>libpthread.so.0</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libpthread.so.0</span> </span></code></pre> Notice how each library has its own unique path in the store. This isolation prevents conflicts between different versions of libraries and enables multiple versions to coexist peacefully.</p> Closures: Complete Dependency Tracking</h2> A "closure" in Nix represents the complete set of dependencies required by a package. Using cryptographic hashes allows Nix to identify the exact</strong> build and runtime dependencies of any package:</p> ~</span></span></span></span> ❯ nix-store -</span>qR</span> $</span>(</span>which</span></span> wget</span>)</span></span></span> </span>/nix/store/6kyaqlxcmfadiiq0mcdj1symv1jsp58w-xgcc-12.3.0-libgcc</span></span> </span>/nix/store/aw137ya6rvy61zw8ydsz22xwarsr8ynf-libunistring-1.1</span></span> </span>/nix/store/vh4pdds47783g12fmywazdx3v3kx0j4x-libidn2-2.3.4</span></span> </span>/nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8</span></span> </span>/nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9</span></span> </span>/nix/store/mgz7sp9jxnk7c3rn1hvich9n0k2rjr7m-zlib-1.2.13</span></span> </span>/nix/store/pxl4n1lrns2xhc8f1s04srb4cphlg5cz-pcre-8.45</span></span> </span>/nix/store/y5975fancsig22f6xw22mmmffn19n8zp-util-linux-minimal-2.39-lib</span></span> </span>/nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4</span></span> </span></code></pre> We can even visualize the dependency graph of a package:</p> ~</span></span></span></span> ❯ nix-store -</span>q</span> --</span>graph</span> $</span>(</span>which</span></span> wget</span>)</span></span></span> </span></code></pre> This will generate a graph showing all relationships between packages:</p> </p> The beauty of closures is that they can be distributed across hosts, which enables powerful distributed build and cache systems:</p> ~</span></span></span></span> ❯ nix copy --</span>to</span> ssh-ng://remote-host /nix/store/qh4y4iw...</span> </span></code></pre> This is the foundation for Nix's distributed builds</a> and binary cache</a> systems.</p> Garbage Collection</h2> Since the Nix store can accumulate packages over time, Nix provides a garbage collection mechanism to reclaim space by removing packages that aren't referenced by any active profiles:</p> ~</span></span></span></span> ❯ nix-collect-garbage</span> </span>finding</span></span> garbage collector roots...</span> </span>removing</span></span> stale temporary roots file '</span>/nix/var/nix/temproots/1023955'</span></span></span> </span>deleting</span></span> garbage...</span> </span>deleting</span></span> '</span>/nix/store/mvqj8avzhkqabkg51cyz617qnhzzawhl-anstyle-wincon-1.0.1'</span></span></span> </span>deleting</span></span> '</span>/nix/store/xzspb26l48b7hlhmlp6ac6sbivil0kgj-rust-operator-deps-0.1.0'</span></span></span> </span>deleting</span></span> '</span>/nix/store/q512fyfmpmdw0ap391j8vkdd8j435545-rust-operator-deps-0.1.0'</span></span></span> </span>deleting</span></span> '</span>/nix/store/gdnzfmns1ryh2pg5z9zbl0jgdspmmmx0-vendor-cargo-deps'</span></span></span> </span>...</span></span> </span>deleting</span></span> unused links...</span> </span>note:</span></span> currently hard linking saves -</span>0</span>.00 MiB</span> </span>1855</span></span> store paths deleted, 7729.65 MiB freed</span> </span></code></pre> The Nix Expression Language</h2> Nix has its own domain-specific language for defining packages and configurations. It has three key characteristics:</p> Pure functional</strong> - functions always produce the same output given the same input</li> Domain specific</strong> - designed specifically for describing packages and their dependencies</li> Lazy evaluation</strong> - expressions are only evaluated when their results are needed</li> </ul> Syntax Basics</h3> Let's explore some basic syntax of the Nix language:</p> # operators</span> </span>1</span> +</span> 2</span> </span>></span> 3</span> </span>[</span> 1</span> 2</span> ]</span> ++</span> [</span> 3</span> ]</span> </span>></span> [</span> 1</span> 2</span> 3</span> ]</span> </span></code></pre> # let ... in ..., allow repeated use of variables in scope</span> </span># string interpolation</span> </span># nix-repl></span> </span>let</span> </span> name</span> =</span> "</span>World"</span></span>;</span> </span>in</span> </span> "</span>hello ${</span>name</span>}</span></span>!"</span></span> </span>></span> hello</span> World</span>!</span> </span></code></pre> # attribute set, attributes accessible by '.'</span> </span># with ..., expose attributes directly</span> </span>let</span> </span> attrs</span> =</span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> false</span>;</span> i</span> =</span> 3</span>;</span> }</span>;</span> </span>in</span> </span> with</span> attrs</span>; [</span> a</span> attrs</span>.</span>b</span> i</span> ]</span> </span>></span> [</span> "</span>str"</span></span> false</span> 3</span> ]</span> </span></code></pre> We can merge attribute sets and use the inherit</code> keyword to bring variables into scope:</p> # merging attr sets</span> </span># dynamic typing</span> </span>let</span> </span> attrs1</span> =</span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> false</span>;</span> }</span>;</span> </span> attrs2</span> =</span> {</span> b</span> =</span> 10</span>;</span> i</span> =</span> 3</span>;</span> }</span>;</span> </span>in</span> </span> attrs1</span> //</span> attrs2</span> </span>></span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> 10</span>;</span> i</span> =</span> 3</span>;</span> }</span> </span></code></pre> # inherit, assign existing values in nested scope</span> </span>let</span> </span> x</span> =</span> {</span> b</span> =</span> 1</span>;</span> }</span>;</span> </span> y</span> =</span> 2</span>;</span> </span> z</span> =</span> false</span>;</span> </span>in</span> </span> {</span> </span> inherit</span> x</span> y</span>;</span> </span> z</span> =</span> z</span>;</span> </span> }</span> </span>></span> {</span> x</span> =</span> {</span> b</span> =</span> 1</span>;</span> }</span>;</span> y</span> =</span> 2</span>;</span> z</span> =</span> false</span>;</span> }</span> </span></code></pre> Functions</h3> In Nix, functions are nameless (lambdas) and always take exactly one argument:</p> # argument: function body</span> </span>let</span> </span> f</span> =</span> x</span>:</span> x</span> +</span> 1</span>;</span> </span>in</span> </span> {</span> </span> type</span> =</span> builtins</span>.</span>typeOf</span> f</span>;</span> </span> result</span> =</span> f</span> 1</span>;</span> </span> }</span> </span>></span> {</span> result</span> =</span> 2</span>;</span> type</span> =</span> "</span>lambda"</span></span>;</span> }</span> </span></code></pre> # nested functions, x: (y: x + y)</span> </span>let</span> </span> f</span> =</span> x</span>:</span> y</span>:</span> x</span> +</span> y</span>;</span> </span>in</span> </span> f</span> 1</span> 2</span> </span>></span> 3</span> </span></code></pre> Functions can also take attribute sets as arguments, with optional default values:</p> # attr set as argument, defined attr must be passed</span> </span># ?, default value</span> </span># ... , extra attrs</span> </span># @name, named attr set</span> </span>let</span> </span> f</span> =</span> {</span>a</span>,</span> b</span> ?</span> 1</span>,</span> ...</span>}</span>@args</span>:</span> a</span> +</span> b</span> +</span> args</span>.</span>c</span>;</span> </span>in</span> </span> f</span> {</span> a</span> =</span> 1</span>;</span> c</span> =</span> 1</span>;</span> }</span> </span>></span> 3</span> </span></code></pre> Domain-Specific Features</h3> Nix has some unique behaviors due to its domain-specific nature. For example, division symbols in paths are interpreted literally:</p> 6/3</span> </span>></span> /Users/mskalski/org/6/3</span> </span></code></pre> let</span> </span> r</span> =</span> 6/3</span>;</span> </span>in</span> </span> builtins</span>.</span>typeOf</span> r</span> </span>></span> "</span>path"</span></span> </span></code></pre> Lazy Evaluation</h3> Nix uses lazy evaluation, meaning expressions are only evaluated when their results are needed:</p> let</span> </span> f</span> =</span> builtins</span>.</span>fetchurl</span> "</span>http://127.0.0.1:8000/f"</span></span>;</span> </span> b</span> =</span> 3</span>;</span> </span>in</span> </span> b</span> </span>></span> 3</span> # no request has been made to http server</span> </span></code></pre> In this example, even though we defined a function to fetch a URL, no network request was made because the result wasn't needed.</p> Practical Nix: What Can I Do With It?</h2> Now that we understand the basics, let's explore some practical applications of Nix.</p> Task Shells: Ephemeral Environments</h3> One of my favorite features is creating ephemeral shells with specific packages:</p> ~ ❯ cowsay "nix is awesome!" </span>Unknown command: cowsay </span> </span>~ ❯ nix-shell -p cowsay </span>[nix-shell:~]$ cowsay "nix is awesome!" </span> _________________ </span>< nix is awesome! > </span> ----------------- </span> \ ^__^ </span> \ (oo)\_______ </span> (__)\ )\/\ </span> \|\|----w \| </span> \|\| \|\| </span> </span>[nix-shell:~]$ exit </span> </span>~ ❯ cowsay "nix is awesome!" </span>Unknown command: cowsay </span></code></pre> This makes it incredibly easy to try out packages without permanently installing them. You can even create ad-hoc environments with specific Python modules:</p> ~</span></span></span></span> ❯ python3 -</span>c</span> "</span>import bcrypt; print(bcrypt.__version__)"</span></span></span> </span>Traceback</span></span> (most recent call last</span></span>):</span></span> </span> File</span></span> "</span><string>"</span></span>, line 1, in <</span>module></span> </span></span>ModuleNotFoundError:</span></span> No module named '</span>bcrypt'</span></span></span> </span> </span>~</span></span></span></span> ❯ nix-shell -</span>p</span> "</span>python3.withPackages(p: [ p.bcrypt ])"</span></span></span> </span>[nix-shell:~</span></span>]$</span></span> python3 -</span>c</span> "</span>import bcrypt; print(bcrypt.__version__)"</span></span></span> </span>4.0.1</span></span> </span></code></pre> Profiles: Persistent Environments with History</h3> Profiles allow you to maintain persistent environments with full rollback capability and atomic updates:</p> #</span></span> Install btop package in user environment (new generation)</span> </span></span>~</span></span></span></span> ❯ nix profile install nixpkgs#btop</span> </span> </span>#</span></span> Compare changes between generations</span> </span></span>~</span></span></span></span> ❯ nix profile diff-closures</span> </span>Version</span></span> 6 -></span> 7</span>:</span> </span> btop:</span></span> ∅ → 1.2.13, +1637.7 KiB</span> </span> gcc:</span></span> ∅ → 12.3.0, +15845.2 KiB</span> </span> glibc:</span></span> ∅ → 2.37-8, +29536.3 KiB</span> </span> libidn2:</span></span> ∅ → 2.3.4, +350.4 KiB</span> </span> libunistring:</span></span> ∅ → 1.1, +1813.8 KiB</span> </span> xgcc:</span></span> ∅ → 12.3.0, +139.1 KiB</span> </span> </span>#</span></span> Revert to previous generation</span> </span></span>~</span></span></span></span> ❯ nix profile rollback</span> </span>switching</span></span> profile from version 7 to 6</span> </span></code></pre> Flakes: Reproducible Definitions</h3> Flakes introduce flake.nix</code> and flake.lock</code> files to provide clear definitions of inputs and their versions. Think of them as similar to package.json and package-lock.json in the Node.js ecosystem, but more powerful.</p> Here is a short recording of me playing with nix flakes:</p>

skalski.dev

The soul of an old machine

2026-04-06T00:00:00+00:00

I somehow get attached to the hardware I use. I think it started in high school when I spent ~3 months choosing an MP3 player, reading dedicated forums and comparing all available models I could afford. After a tedious process I used it for years, probably longer than I was supposed to, falling behind trends. That pattern stuck. In the process of choosing a new device I usually tried to find a unique candidate. Not the most popular choice, but something that had characteristics not available in other products.

When I was on the market for my first notebook during my university years, instead of the raw specs I was looking for durability and serviceability. ThinkPads were out of my financial range but HP Compaq nx6310</a> was close. It still powers on after 20 years. I kept it running for me, later for my parents once I started getting work notebooks. That was the piece of hardware where I installed my first Linux distribution - Ubuntu 6.06 from the CD they sent to you</a>, later Gentoo, also from a CD attached to some Linux magazine. I remember the "the future is here" moment, holding a Motorola Droid</a> and starting an OpenOffice compilation remotely on my laptop, hoping that once I got back home it would be finished. A lot of activities and hobbies happened around and through these devices, and it was the pre-social network era.

The attachment to old hardware requires some commitment, especially if the device wasn't built to last. If it was popular enough there is a chance to find a community around it which concentrates on keeping it alive and improving it, and it can be a rewarding process. The iPod 5th gen</a> got a second life after replacing internal hdd with sd card</a> and a fresh, bigger battery. Installing Rockbox</a> gave it more capabilities. Sometimes it is more of a necessity to keep something alive. A couple of hours before my flight to a new country where I started a new chapter in my life I sat in my parents' kitchen and soldered an extra resistor to the motherboard of the NAS I wanted to leave for them. That was the best moment for LPC clock degradation issue with the Intel Celeron J1900</a> to emerge.

In 2014 I received a MacBook Pro, 13-inch Late 2013</a> at my new work place. That wasn't the first encounter with Apple products though. At the end of elementary school our newly opened computer lab was equipped with lovely iMac G3s</a>, which were all stolen after a few months. To this day I remember the Monday morning at school finding out what happened and stepping on some keys from keyboards lying around in the corridor. Hmm, so maybe that's when I started getting attached to hardware? Anyway, after a few days I got used to the new notebook and enjoyed it. At that time I was impressed by the operating system, the look and the quality of the apps. The fact that I could attend online meetings, share the screen without worrying what might not work this time and had access to a Unix shell and familiar programs was a new world for me.

The thrill faded over the years, especially in terms of look and user experience. These days, if possible, I am using sway</a> tiling window manager with basic config. The keyboard driven workflow is in my muscle memory, and my fingers like to stay on the keys of hhkb</a>, another device which stays with me. Yet the hardware part of the MacBook remains relevant even after all those years. Sure, the CPU shows its age, which you can feel when browsing the modern internet, but only in 2024 when I bought a 4K monitor, the limitations of Intel Iris Graphics became more obvious. It couldn't drive it at native resolution at 60Hz. That being said, the screen of this notebook is its most appealing part. It was one of the first models with a Retina display. I often looked at used ThinkPads, which have much better serviceability and support under Linux. But the resolution and colors of the screen on the device I already had kept me from buying one. The keyboard is OK, assembled before all the dramas</a>. The aluminum body remains strong and solid. The trackpad is top-notch.

When I was changing employers, I bought it out and took it with me. The official support ended on Big Sur release. It could be pushed further with OpenCore</a> but nowadays I only use macOS on it to run pre-cloud Lightroom and negative lab pro</a> to "develop" some of my film scans</a>. I'm running NixOS</a> on it most of the time, without any hardware support issues. Maybe sometimes the red light from the S/PDIF digital output becomes visible. It's a twelve-year-old machine, but it rarely feels like one. Emacs with rust-analyzer/gopls works fine for smaller projects locally. For those projects which benefit from better specs I can use it to remotely attach to my desktop. Websites like Reddit or YouTube tend to spin up the fan, a reminder of the actual age. I guess it has become more of a writer deck</a>, a distraction-free machine for writing and focused work.

I recently updated my Nix flake for this MacBook to use NixOS 25.11 channel and my config could no longer build. The reason was that broadcom_sta</code> driver was marked as insecure</a> due to known, unresolved CVE issues. Combining this with the already existing lack of WPA3 support, I started looking into alternatives. The problem, as often with Apple hardware, is that they use a proprietary connector instead of a standard M.2. After some searching, I found an adapter on AliExpress described as "WIFI 6 AX200 AX210 adapter for MacBook Pro A1502 A1398". I ordered it together with an Intel AX210 card which has good support under Linux through the iwlwifi</code> driver. When the parts arrived, I opened the case and found an unpleasant surprise. The battery showed signs of swelling.

It wasn't the original battery. I had replaced it in May 2023 with ifixit kit</a> because of the same symptoms. This time I couldn't order the same as they don't send batteries to Japan, so I found a kit on local Amazon. After replacing all the components, I had an issue with initializing the new Wi-Fi card during boot, but not always. I quickly connected the dots that it only happened when the computer was on battery power, and commented out the following in my TLP config</a>:

PCIE_ASPM_ON_BAT= "powersupersave"
</span></code></pre>
I probably gained another year with this machine. It traveled with me through three continents and lasted longer than the manufacturer envisioned, I think. Last year I replaced my iPhone 8 with a 16, mainly because security updates weren't provided anymore, but I hardly found a feature to be excited about. No "the future is here" moment this time. Most devices today follow the same shape and the same cycle. That makes it worth searching for the ones with some soul to them, the ones built to last. Recently, ThinkPads seem to be going back</a> to their easy serviceability roots, and the Framework laptops continue to prove that there is a market for devices like that.</p>



About absence of a sum type in Go
2026-02-11T00:00:00+00:00
Recently I was building an infrastructure-as-code library for Google Cloud. One of the things I needed was a function to create Eventarc</a> triggers. The function needed to accept a destination - where should events be delivered?</p>
Looking at the Eventarc REST API</a>, the destination is defined as a union field. It can be one of several things: a Cloud Run service, an HTTP endpoint, a Cloud Function, a GKE service, or a Workflow. Exactly one must be set.</p>
{
</span>  // Union field descriptor can be only one of the following:
</span>  "cloudRun": { },
</span>  "cloudFunction": "...",
</span>  "gke": { },
</span>  "workflow": "...",
</span>  "httpEndpoint": { }
</span>}
</span></code></pre>
This is an example of sum type</a> (also called a tagged union or discriminated union). A value that can be exactly one of N known alternatives. Go doesn't have sum types, and how you work around that absence turns out to be an interesting exercise.</p>
My function signature looked something like this:</p>
func</span> NewTrigger</span>(</span>name</span> string</span></span>,</span> dest</span> Destination</span>,</span> eventType</span> EventType</span>)</span> error</span></span>
</span></code></pre>
The question was how to define Destination</code> so that callers are guided toward correct usage and invalid states are caught early.</p>
The simplest thing that could work was a struct. Unexported fields, a constructor function:</p>
type</span> Destination</span> struct</span> {</span>
</span></span>    cloudRun</span> *</span>cloudRunConfig</span>
</span></span>}</span></span>
</span>
</span>type</span> cloudRunConfig</span> struct</span> {</span>
</span></span>    service</span> string</span></span>
</span></span>    region</span>  string</span></span>
</span></span>}</span></span>
</span>
</span>func</span> CloudRunDestination</span>(</span>service</span>,</span> region</span> string</span></span>)</span> Destination</span> {</span>
</span></span>    return</span> Destination</span>{</span>cloudRun</span>:</span> &</span>cloudRunConfig</span>{</span>service</span>:</span> service</span>,</span> region</span>:</span> region</span>}</span></span>}</span></span>
</span></span>}</span></span>
</span></code></pre>
It looks reasonable. The fields are unexported, so callers can't mess with the internals. They use the constructor, they get a valid destination. But there's a problem that's easy to miss.</p>
In Go, every type has a zero value. For a struct, that means all fields set to their zero values. Which means this compiles perfectly:</p>
dest</span> :=</span> Destination</span>{</span>}</span></span>
</span>err</span> :=</span> NewTrigger</span>(</span>"</span>my-trigger"</span></span>,</span> dest</span>,</span> someEvent</span>)</span>
</span></code></pre>
The caller passed an empty Destination</code>. No Cloud Run config, no HTTP endpoint, nothing. The code compiles. The linter is happy. You won't find out until runtime apply the configuration when it fails with some cryptic error about a missing destination.</p>
It gets worse as you add more destination types. With two fields someone could theoretically set both, or neither. With five you need validation that checks "exactly one of these N fields is non-nil". It's doable, but you're reimplementing by hand what a type system could give you.</p>
I went looking for better patterns and found discussions around "sealed interfaces" - a pattern used in Go's standard library</a>. There's a Reddit thread</a> debating the merits of this approach. The idea is to define an unexported interface that only types within your package can implement. Since the interface or its method is unexported, nobody outside the package can satisfy it.</p>
Here's what I ended up with:</p>
type</span> Destination</span> struct</span> {</span>
</span></span>    dest</span> destinationType</span>
</span></span>}</span></span>
</span>
</span>type</span> destinationType</span> interface</span> {</span>
</span></span>    isDestination</span>(</span>)</span> //</span> unexported method seals the interface
</span></span></span>}</span></span>
</span>
</span>type</span> cloudRunConfig</span> struct</span> {</span>
</span></span>    service</span> string</span></span>
</span></span>    region</span>  string</span></span>
</span></span>}</span></span>
</span>
</span>func</span> (</span>*</span>cloudRunConfig</span>)</span></span> isDestination</span></span>(</span>)</span> {</span>}</span></span>
</span>
</span>func</span> CloudRunDestination</span>(</span>service</span>,</span> region</span> string</span></span>)</span> Destination</span> {</span>
</span></span>    return</span> Destination</span>{</span>dest</span>:</span> &</span>cloudRunConfig</span>{</span>service</span>:</span> service</span>,</span> region</span>:</span> region</span>}</span></span>}</span></span>
</span></span>}</span></span>
</span></code></pre>
full example on go playground</a></em></p>
I think it is better approach than the previous one. The destinationType</code> interface can only be implemented inside the package, so the set of valid destination types is closed. You can't accidentally set multiple variants because there's only one field. When I add an HTTP endpoint variant later, it's just another type that implements isDestination()</code>, and Destination</code> still holds exactly one of them.</p>
But the zero value problem didn't go away:</p>
dest</span> :=</span> Destination</span>{</span>}</span></span> //</span> dest.dest is nil — compiles, still invalid
</span></span></code></pre>
I still need a runtime check inside NewTrigger</code>:</p>
if</span> dest</span>.</span>dest</span> ==</span> nil</span> {</span>
</span></span>    return</span> errors</span>.</span>New</span>(</span>"</span>destination not set; use a constructor like CloudRunDestination()"</span></span>)</span>
</span></span>}</span></span>
</span></code></pre>
It works. The error message is clear. The invalid state is caught before it causes damage downstream. But it's caught at runtime, not at compile time. The compiler doesn't help you here.</p>
The Go community has been discussing sum types for years. There's proposal #19412</a> from 2017 and a more specific proposal #57644</a> that suggests extending interfaces to support type unions:</p>
type</span> Destination</span> interface</span> {</span>
</span></span>    CloudRunConfig</span> |</span> HttpEndpointConfig</span> |</span> GKEConfig</span>
</span></span>}</span></span>
</span></code></pre>
This would make the sealed interface pattern a first-class language feature instead of an idiom you have to know about. One of the comments on that proposal</a> describes almost exactly the pattern I ended up using - an unexported method to seal the interface - and points out how the proposal would reduce the boilerplate and make the intent explicit.</p>
But there's a catch that the proposal authors themselves acknowledge. In Go, every interface has a zero value, and that zero value is nil</code>. Even with union interfaces in the language, you'd still be able to write:</p>
var</span> dest</span> Destination</span> //</span> nil — compiles fine
</span></span></code></pre>
The proposal text says it directly:</p>

this is a form of sum type in which there is always another possible option, namely nil. Sum types in most languages do not work this way, and this may be a reason to not add this functionality to Go.</p>
</blockquote>
The zero value principle is deeply embedded in Go's design. It's a deliberate choice that makes many things simpler. You can declare a sync.Mutex</code> or a bytes.Buffer</code> and use it immediately, no constructor needed. But when you're modeling something where "nothing" is not a valid state, that same principle works against you.</p>
This got me curious about how Rust handles the same problem. In Rust, the destination type would be:</p>
enum</span> Destination</span> {</span>
</span></span></span>    CloudRun {</span> service:</span> String</span>,</span> region:</span> String</span>,</span> path:</span> Option</span><</span>String</span>></span></span> </span>}</span></span>,</span>
</span></span></span>    HttpEndpoint {</span> uri:</span> String</span> </span>}</span></span>,</span>
</span></span></span>    Gke {</span> cluster:</span> String</span>,</span> location:</span> String</span>,</span> namespace:</span> String</span>,</span> service:</span> String</span> </span>}</span></span>,</span>
</span></span></span>    Workflow(</span>String</span></span>)</span></span>,</span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
example on rust playground</a></em></p>
That's it. No wrapper struct. No sealed interface. No unexported methods. No constructors needed. The enum definition says everything: a Destination</code> is one of these four things, and nothing else.</p>
There's no zero value. You can't construct a Destination</code> without choosing a variant. The type system forces the decision, and it forces it at compile time.</p>
When you consume the destination, exhaustive pattern matching makes sure you handle every case:</p>
fn</span> </span>configure_trigger</span></span>(</span>dest</span>:</span> Destination</span>)</span></span></span></span> </span>{</span>
</span></span></span>    match</span> dest {</span>
</span></span></span></span>        Destination::</span></span>CloudRun {</span> service,</span> region,</span> path </span>}</span></span> =></span> {</span> /*</span> ... */</span></span> </span>}</span></span>
</span></span></span></span>        Destination::</span></span>HttpEndpoint {</span> uri </span>}</span></span> =></span> {</span> /*</span> ... */</span></span> </span>}</span></span>
</span></span></span></span>        Destination::</span></span>Gke {</span> ..</span> </span>}</span></span> =></span> {</span> /*</span> ... */</span></span> </span>}</span></span>
</span></span></span></span>        Destination::</span></span>Workflow(</span>name</span>)</span></span> =></span> {</span> /*</span> ... */</span></span> </span>}</span></span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
If I add a fifth variant six months later, every match</code> expression that doesn't handle it becomes a compile error. The compiler tells me exactly where I need to update. In Go, adding a new type that implements destinationType</code> compiles everywhere silently. I have to search through type switches and hope I didn't miss any. For an internal library where my team owns all the code - that exhaustiveness is what I want. A missed destination type means a misconfigured trigger that fails at deploy time, so I'd rather hear about it from the compiler. For a public library, that same property becomes disruptive - adding a new variant breaks downstream consumer and forces a major release. Rust acknowledges this with the #[non_exhaustive]</code></a> attribute, which lets you keep exhaustiveness within your own crate while allowing external callers to gracefully ignore new variants.</p>
Go's simplicity is real and valuable. The zero value concept eliminates an entire class of "forgot to initialize" bugs that other languages struggle with. The sealed interface pattern I used works in practice - the runtime error is caught early, the message is helpful.</p>
However there's something satisfying about a language that lets you say "a destination is one of these things" and then enforces that statement everywhere, at compile time, with no extra work. The Rust enum doesn't need discipline or idiom knowledge. It doesn't need runtime validation because the invalid state simply doesn't exist.</p>


Understanding Nix: A Purely Functional Approach to Package Management
2025-05-10T00:00:00+00:00
This article is based on the presentation I made a while ago about Nix and NixOS. The presentation can be seen here</a>.</em></p>
Over the past few years, I've been exploring different approaches to managing software environments and deployments. Among them, Nix has stood out as a fascinating solution that takes a fundamentally different approach. In this post, I'll share what I've learned about Nix and why it might be worth your attention.</p>
What is Nix?</h2>
Nix is simultaneously three interconnected things:</p>

A domain-specific language</strong> with functional programming characteristics</li>
A powerful package manager</a></strong> with unique properties</li>
The main pillar of NixOS</a></strong>, a Linux distribution built around Nix principles</li>
</ul>
Origins</h2>
Nix began as the PhD project of Eelco Dolstra, crystallized in these academic papers:</p>

Imposing a Memory Management Discipline on Software Deployment (2004)</a></strong></li>
The Purely Functional Software Deployment Model (2005)</a></strong></li>
</ul>
Initially, Nix was intended to be an alternative to traditional build systems like make</code> and package managers like rpm</code>. However, it has evolved into something much more comprehensive.</p>
For those interested in a deeper historical perspective, I recommend watching Eelco Dolstra's talk on The Evolution of Nix</a>.</p>
Problems Nix Attempts to Solve</h2>
Traditional package managers face several persistent challenges that anyone who has managed systems will recognize:</p>

DLL hell</strong> - conflicting shared libraries causing application failures</li>
Destructive upgrades</strong> - installing a new version overwrites the previous one</li>
No rollbacks</strong> - difficult or impossible to return to previous states</li>
Not atomic</strong> - system left in inconsistent state if updates are interrupted</li>
Hard to prevent undeclared dependencies</strong> - applications might depend on libraries that aren't explicitly listed</li>
</ul>
These issues stem from the fundamental design of how software is installed and managed in conventional systems.</p>
Understanding the Traditional Approach: Filesystem Hierarchy Standard</h2>
To understand what makes Nix different, let's first look at how traditional systems handle software installation. In standard Linux distributions, packages install files in fixed locations according to the Filesystem Hierarchy Standard</a>:</p>
#</span></span> list of files installed on filesystem by wget pkg</span>
</span></span>~</span></span></span></span> ❯ dpkg -</span>L</span> wget</span>
</span>...</span></span>
</span>/etc/wgetrc</span></span>
</span>/usr/bin/wget</span></span>
</span>/usr/share/doc/wget/README</span></span>
</span>/usr/share/man/man1/wget.1.gz</span></span>
</span></code></pre>
Programs often rely on dynamically linked libraries that are shared across the system:</p>
#</span></span> dynamically linked libraries</span>
</span></span>~</span></span></span></span> ❯ ldd /usr/bin/wget</span>
</span>libpcre2-8.so.0</span></span> =></span> /lib/x86_64-linux-gnu/libpcre2-8.so.0</span>
</span>libuuid.so.1</span></span> =></span> /lib/x86_64-linux-gnu/libuuid.so.1</span>
</span>libidn2.so.0</span></span> =></span> /lib/x86_64-linux-gnu/libidn2.so.0</span>
</span>libssl.so.3</span></span> =></span> /lib/x86_64-linux-gnu/libssl.so.3</span>
</span>libcrypto.so.3</span></span> =></span> /lib/x86_64-linux-gnu/libcrypto.so.3</span>
</span>libz.so.1</span></span> =></span> /lib/x86_64-linux-gnu/libz.so.1</span>
</span>libpsl.so.5</span></span> =></span> /lib/x86_64-linux-gnu/libpsl.so.5</span>
</span>libc.so.6</span></span> =></span> /lib/x86_64-linux-gnu/libc.so.6</span>
</span>/lib64/ld-linux-x86-64.so.2</span></span>
</span>libunistring.so.2</span></span> =></span> /lib/x86_64-linux-gnu/libunistring.so.2</span>
</span></code></pre>
Filesystem as Memory: A Novel Approach</h2>
One of Nix's breakthrough insights was drawing a parallel between memory management in programming languages and package management in operating systems. Dolstra visualized the filesystem as analogous to program memory.</p>
Here's how concepts map between programming languages and deployment systems:</p>
Programming Language Domain</th> Deployment Domain</th></tr></thead>

memory</td> disk</td></tr>
value, object</td> file</td></tr>
address</td> path name</td></tr>
pointer dereference</td> file access</td></tr>
pointer arithmetic</td> string operations</td></tr>
dangling pointer</td> path to absent file</td></tr>
object graph</td> dependency graph</td></tr>
calling constructed object with reference to other object</td> runtime dependency</td></tr>
calling constructor with reference to other object, not stored</td> build-time dependency</td></tr>
calling constructor with reference to other object, stored</td> retained dependency</td></tr>
languages without pointer discipline (e.g. assembler)</td> typical Unix-style deployment</td></tr>
languages with enough pointer discipline to support conservative garbage collection (e.g. C, C++)</td> Nix</td></tr>
languages with full pointer discipline (e.g. Java, Haskell)</td> as-yet unknown deployment style not enabled by contemporary operating systems</td></tr>
</tbody></table>
This model suggests viewing the file system as memory and package management as memory management. That reshapes how we can think about software deployment.</p>
Isolation and Reliable Identification</h2>
One of the challenge in package management is avoiding file path collisions. When multiple packages want to install files to the same location, conflicts arise. Traditional approaches have limitations:</p>

Using component name and version alone isn't sufficient (what about different build options?)</li>
Random allocation would be inefficient and generate duplicates</li>
</ul>
The Hash Solution</h2>
Nix's approach is to compute a cryptographic hash of all inputs that affect a package, including:</p>

The sources</strong> of the components</li>
The build script</strong> that performed the build</li>
Any arguments or environment variables</strong> passed to the build script</li>
All build time dependencies</strong>, including compilers, linkers, libraries, standard Unix tools, shells, etc.</li>
</ul>
This hash becomes part of the path where the package is stored, ensuring that different versions or builds of the same package can coexist without conflicts.</p>
The Nix Store</h2>
The cornerstone of Nix is the /nix/store</strong> directory, where all packages are stored using their unique hash identifiers. For example:</p>
~</span></span></span></span> ❯ which wget</span>
</span>/nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4/bin/wget</span></span>
</span>
</span>~</span></span></span></span> ❯ ldd /nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4/bin/wget</span>
</span>libpcre.so.1</span></span> =></span> /nix/store/pxl4n1lrns2xhc8f1s04srb4cphlg5cz-pcre-8.45/lib/libpcre.so.1</span>
</span>libuuid.so.1</span></span> =></span> /nix/store/y5975fancsig22f6xw22mmmffn19n8zp-util-linux-minimal-2.39-lib/lib/libuuid.so.1</span>
</span>libidn2.so.0</span></span> =></span> /nix/store/vh4pdds47783g12fmywazdx3v3kx0j4x-libidn2-2.3.4/lib/libidn2.so.0</span>
</span>libssl.so.3</span></span> =></span> /nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9/lib/libssl.so.3</span>
</span>libcrypto.so.3</span></span> =></span> /nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9/lib/libcrypto.so.3</span>
</span>libz.so.1</span></span> =></span> /nix/store/mgz7sp9jxnk7c3rn1hvich9n0k2rjr7m-zlib-1.2.13/lib/libz.so.1</span>
</span>libc.so.6</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libc.so.6</span>
</span>libunistring.so.5</span></span> =></span> /nix/store/aw137ya6rvy61zw8ydsz22xwarsr8ynf-libunistring-1.1/lib/libunistring.so.5</span>
</span>libdl.so.2</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libdl.so.2</span>
</span>libpthread.so.0</span></span> =></span> /nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8/lib/libpthread.so.0</span>
</span></code></pre>
Notice how each library has its own unique path in the store. This isolation prevents conflicts between different versions of libraries and enables multiple versions to coexist peacefully.</p>
Closures: Complete Dependency Tracking</h2>
A "closure" in Nix represents the complete set of dependencies required by a package. Using cryptographic hashes allows Nix to identify the exact</strong> build and runtime dependencies of any package:</p>
~</span></span></span></span> ❯ nix-store -</span>qR</span> $</span>(</span>which</span></span> wget</span>)</span></span></span>
</span>/nix/store/6kyaqlxcmfadiiq0mcdj1symv1jsp58w-xgcc-12.3.0-libgcc</span></span>
</span>/nix/store/aw137ya6rvy61zw8ydsz22xwarsr8ynf-libunistring-1.1</span></span>
</span>/nix/store/vh4pdds47783g12fmywazdx3v3kx0j4x-libidn2-2.3.4</span></span>
</span>/nix/store/ayg065nw0xi1zsyi8glfh5pn4sfqd8xg-glibc-2.37-8</span></span>
</span>/nix/store/ix7cb1isdcdl4gq9hl4pdk6gyc4wrk14-openssl-3.0.9</span></span>
</span>/nix/store/mgz7sp9jxnk7c3rn1hvich9n0k2rjr7m-zlib-1.2.13</span></span>
</span>/nix/store/pxl4n1lrns2xhc8f1s04srb4cphlg5cz-pcre-8.45</span></span>
</span>/nix/store/y5975fancsig22f6xw22mmmffn19n8zp-util-linux-minimal-2.39-lib</span></span>
</span>/nix/store/d3kkv9vjb3ljh7hr5v38gls8iykvwkny-wget-1.21.4</span></span>
</span></code></pre>
We can even visualize the dependency graph of a package:</p>
~</span></span></span></span> ❯ nix-store -</span>q</span> --</span>graph</span> $</span>(</span>which</span></span> wget</span>)</span></span></span>
</span></code></pre>
This will generate a graph showing all relationships between packages:</p>
</p>
The beauty of closures is that they can be distributed across hosts, which enables powerful distributed build and cache systems:</p>
~</span></span></span></span> ❯ nix copy --</span>to</span> ssh-ng://remote-host /nix/store/qh4y4iw...</span>
</span></code></pre>
This is the foundation for Nix's distributed builds</a> and binary cache</a> systems.</p>
Garbage Collection</h2>
Since the Nix store can accumulate packages over time, Nix provides a garbage collection mechanism to reclaim space by removing packages that aren't referenced by any active profiles:</p>
~</span></span></span></span> ❯ nix-collect-garbage</span>
</span>finding</span></span> garbage collector roots...</span>
</span>removing</span></span> stale temporary roots file '</span>/nix/var/nix/temproots/1023955'</span></span></span>
</span>deleting</span></span> garbage...</span>
</span>deleting</span></span> '</span>/nix/store/mvqj8avzhkqabkg51cyz617qnhzzawhl-anstyle-wincon-1.0.1'</span></span></span>
</span>deleting</span></span> '</span>/nix/store/xzspb26l48b7hlhmlp6ac6sbivil0kgj-rust-operator-deps-0.1.0'</span></span></span>
</span>deleting</span></span> '</span>/nix/store/q512fyfmpmdw0ap391j8vkdd8j435545-rust-operator-deps-0.1.0'</span></span></span>
</span>deleting</span></span> '</span>/nix/store/gdnzfmns1ryh2pg5z9zbl0jgdspmmmx0-vendor-cargo-deps'</span></span></span>
</span>...</span></span>
</span>deleting</span></span> unused links...</span>
</span>note:</span></span> currently hard linking saves -</span>0</span>.00 MiB</span>
</span>1855</span></span> store paths deleted, 7729.65 MiB freed</span>
</span></code></pre>
The Nix Expression Language</h2>
Nix has its own domain-specific language for defining packages and configurations. It has three key characteristics:</p>

Pure functional</strong> - functions always produce the same output given the same input</li>
Domain specific</strong> - designed specifically for describing packages and their dependencies</li>
Lazy evaluation</strong> - expressions are only evaluated when their results are needed</li>
</ul>
Syntax Basics</h3>
Let's explore some basic syntax of the Nix language:</p>
# operators</span>
</span>1</span> +</span> 2</span>
</span>></span> 3</span>
</span>[</span> 1</span> 2</span> ]</span> ++</span> [</span> 3</span> ]</span>
</span>></span> [</span> 1</span> 2</span> 3</span> ]</span>
</span></code></pre>
# let ... in ..., allow repeated use of variables in scope</span>
</span># string interpolation</span>
</span># nix-repl></span>
</span>let</span>
</span>    name</span> =</span> "</span>World"</span></span>;</span>
</span>in</span>
</span>    "</span>hello ${</span>name</span>}</span></span>!"</span></span>
</span>></span> hello</span> World</span>!</span>
</span></code></pre>
# attribute set, attributes accessible by '.'</span>
</span># with ..., expose attributes directly</span>
</span>let</span>
</span>    attrs</span> =</span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> false</span>;</span> i</span> =</span> 3</span>;</span> }</span>;</span>
</span>in</span>
</span>    with</span> attrs</span>; [</span> a</span> attrs</span>.</span>b</span> i</span> ]</span>
</span>></span> [</span> "</span>str"</span></span> false</span> 3</span> ]</span>
</span></code></pre>
We can merge attribute sets and use the inherit</code> keyword to bring variables into scope:</p>
# merging attr sets</span>
</span># dynamic typing</span>
</span>let</span>
</span>    attrs1</span> =</span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> false</span>;</span> }</span>;</span>
</span>    attrs2</span> =</span> {</span> b</span> =</span> 10</span>;</span> i</span> =</span> 3</span>;</span> }</span>;</span>
</span>in</span>
</span>    attrs1</span> //</span> attrs2</span>
</span>></span> {</span> a</span> =</span> "</span>str"</span></span>;</span> b</span> =</span> 10</span>;</span> i</span> =</span> 3</span>;</span> }</span>
</span></code></pre>
# inherit, assign existing values in nested scope</span>
</span>let</span>
</span>    x</span> =</span> {</span> b</span> =</span> 1</span>;</span> }</span>;</span>
</span>    y</span> =</span> 2</span>;</span>
</span>    z</span> =</span> false</span>;</span>
</span>in</span>
</span>    {</span>
</span>      inherit</span> x</span> y</span>;</span>
</span>      z</span> =</span> z</span>;</span>
</span>    }</span>
</span>></span> {</span> x</span> =</span> {</span> b</span> =</span> 1</span>;</span> }</span>;</span> y</span> =</span> 2</span>;</span> z</span> =</span> false</span>;</span> }</span>
</span></code></pre>
Functions</h3>
In Nix, functions are nameless (lambdas) and always take exactly one argument:</p>
# argument: function body</span>
</span>let</span>
</span>    f</span> =</span> x</span>:</span> x</span> +</span> 1</span>;</span>
</span>in</span>
</span>    {</span>
</span>      type</span> =</span> builtins</span>.</span>typeOf</span> f</span>;</span>
</span>      result</span> =</span> f</span> 1</span>;</span>
</span>    }</span>
</span>></span> {</span> result</span> =</span> 2</span>;</span> type</span> =</span> "</span>lambda"</span></span>;</span> }</span>
</span></code></pre>
# nested functions, x: (y: x + y)</span>
</span>let</span>
</span>    f</span> =</span> x</span>:</span> y</span>:</span> x</span> +</span> y</span>;</span>
</span>in</span>
</span>    f</span> 1</span> 2</span>
</span>></span> 3</span>
</span></code></pre>
Functions can also take attribute sets as arguments, with optional default values:</p>
# attr set as argument, defined attr must be passed</span>
</span># ?, default value</span>
</span># ... , extra attrs</span>
</span># @name, named attr set</span>
</span>let</span>
</span>    f</span> =</span> {</span>a</span>,</span> b</span> ?</span> 1</span>,</span> ...</span>}</span>@args</span>:</span> a</span> +</span> b</span> +</span> args</span>.</span>c</span>;</span>
</span>in</span>
</span>    f</span> {</span> a</span> =</span> 1</span>;</span> c</span> =</span> 1</span>;</span> }</span>
</span>></span> 3</span>
</span></code></pre>
Domain-Specific Features</h3>
Nix has some unique behaviors due to its domain-specific nature. For example, division symbols in paths are interpreted literally:</p>
6/3</span>
</span>></span> /Users/mskalski/org/6/3</span>
</span></code></pre>
let</span>
</span>    r</span> =</span> 6/3</span>;</span>
</span>in</span>
</span>    builtins</span>.</span>typeOf</span> r</span>
</span>></span> "</span>path"</span></span>
</span></code></pre>
Lazy Evaluation</h3>
Nix uses lazy evaluation, meaning expressions are only evaluated when their results are needed:</p>
let</span>
</span>    f</span> =</span> builtins</span>.</span>fetchurl</span> "</span>http://127.0.0.1:8000/f"</span></span>;</span>
</span>    b</span> =</span> 3</span>;</span>
</span>in</span>
</span>    b</span>
</span>></span> 3</span> # no request has been made to http server</span>
</span></code></pre>
In this example, even though we defined a function to fetch a URL, no network request was made because the result wasn't needed.</p>
Practical Nix: What Can I Do With It?</h2>
Now that we understand the basics, let's explore some practical applications of Nix.</p>
Task Shells: Ephemeral Environments</h3>
One of my favorite features is creating ephemeral shells with specific packages:</p>
~ ❯ cowsay "nix is awesome!"
</span>Unknown command: cowsay
</span>
</span>~ ❯ nix-shell -p cowsay
</span>[nix-shell:~]$ cowsay "nix is awesome!"
</span> _________________
</span>< nix is awesome! >
</span> -----------------
</span>        \   ^__^
</span>         \  (oo)\_______
</span>            (__)\       )\/\
</span>                ||----w |
</span>                ||     ||
</span>
</span>[nix-shell:~]$ exit
</span>
</span>~ ❯ cowsay "nix is awesome!"
</span>Unknown command: cowsay
</span></code></pre>
This makes it incredibly easy to try out packages without permanently installing them. You can even create ad-hoc environments with specific Python modules:</p>
~</span></span></span></span> ❯ python3 -</span>c</span> "</span>import bcrypt; print(bcrypt.__version__)"</span></span></span>
</span>Traceback</span></span> (most recent call last</span></span>):</span></span>
</span>  File</span></span> "</span><string>"</span></span>, line 1, in <</span>module></span>
</span></span>ModuleNotFoundError:</span></span> No module named '</span>bcrypt'</span></span></span>
</span>
</span>~</span></span></span></span> ❯ nix-shell -</span>p</span> "</span>python3.withPackages(p: [ p.bcrypt ])"</span></span></span>
</span>[nix-shell:~</span></span>]$</span></span> python3 -</span>c</span> "</span>import bcrypt; print(bcrypt.__version__)"</span></span></span>
</span>4.0.1</span></span>
</span></code></pre>
Profiles: Persistent Environments with History</h3>
Profiles allow you to maintain persistent environments with full rollback capability and atomic updates:</p>
#</span></span> Install btop package in user environment (new generation)</span>
</span></span>~</span></span></span></span> ❯ nix profile install nixpkgs#btop</span>
</span>
</span>#</span></span> Compare changes between generations</span>
</span></span>~</span></span></span></span> ❯ nix profile diff-closures</span>
</span>Version</span></span> 6 -></span> 7</span>:</span>
</span>  btop:</span></span> ∅ → 1.2.13, +1637.7 KiB</span>
</span>  gcc:</span></span> ∅ → 12.3.0, +15845.2 KiB</span>
</span>  glibc:</span></span> ∅ → 2.37-8, +29536.3 KiB</span>
</span>  libidn2:</span></span> ∅ → 2.3.4, +350.4 KiB</span>
</span>  libunistring:</span></span> ∅ → 1.1, +1813.8 KiB</span>
</span>  xgcc:</span></span> ∅ → 12.3.0, +139.1 KiB</span>
</span>
</span>#</span></span> Revert to previous generation</span>
</span></span>~</span></span></span></span> ❯ nix profile rollback</span>
</span>switching</span></span> profile from version 7 to 6</span>
</span></code></pre>
Flakes: Reproducible Definitions</h3>
Flakes introduce flake.nix</code> and flake.lock</code> files to provide clear definitions of inputs and their versions. Think of them as similar to package.json and package-lock.json in the Node.js ecosystem, but more powerful.</p>
Here is a short recording of me playing with nix flakes:</p>

skalski.dev

The soul of an old machine

About absence of a sum type in Go

Understanding Nix: A Purely Functional Approach to Package Management

What is Nix?</h2> Nix is simultaneously three interconnected things:</p> A domain-specific language</strong> with functional programming characteristics</li>

Origins</h2> Nix began as the PhD project of Eelco Dolstra, crystallized in these academic papers:</p>

Practical Nix: What Can I Do With It?</h2> Now that we understand the basics, let's explore some practical applications of Nix.</p>

Practical Nix: What Can I Do With It?</h2>
Now that we understand the basics, let's explore some practical applications of Nix.</p>