Nix in the Wild: Sift Technologies

6 July 2023

Nix in the Wild is a series where we dive into the stories of Nix users across the industry, covering everything from the dotfiles of crafty developers to the processes of engineering leaders in large organizations. Learn where Nix is used, how it came to be, and why it works the way it does.

In a recent interview, we had the opportunity to speak with Tom Dimiduk, a PhD in physics who ventured into software development, and the spotlight was on his company, Sift Technologies. Sift Technologies specializes in human curation, offering trusted recommendations and facilitating recommendations from people to people.

One of the tools they leverage in their work is Nix, a powerful package manager and operating system configuration tool.

Tom Dimiduk's journey into Nix began approximately 10 years ago when he first became aware of its existence. As he delved deeper into Nix, he realized that it was a great solution for managing complex software environments. “It clicked in my brain. This is how you should manage computers,” he said. Tom has used Nix in various ways on personal computers since then, increasing in frequency as Nix and NixOS matured. In his previous life as a scientist, he saw the applicability of Nix for research purposes, where the ability to recreate specific conditions is essential.

Today, Nix finds extensive usage within Sift Technologies, particularly in conjunction with Haskell, their programming language of choice. Tom explains that Nix aligns with their preference for declarative management, enabling them to efficiently manage servers and development environments.

The payoff of using Nix has been clearly evident, and the Sift developers appreciate the reassurance provided by the ability to roll back configurations when needed. Tom emphasizes the ability to trace chains of trust, praising Nix for providing a level of proof and guarantees that other package management systems lack.

Despite the successes, there have been hurdles along the way. Tom admits that the team has yet to completely grasp the Nix language, relying on trial and error and not truly understanding its inner workings. While Nix has proven useful for running servers and setting up development environments, he highlights the need for a comprehensive introductory guide that explains Nix from the ground up. Additionally, the lack of authoritative reference documentation and the presence of experimental commands have made the learning process challenging. Tom believes that a well-curated beginner-to-intermediate guide with best practices would greatly benefit newcomers to Nix.

When asked about his advice to those considering using Nix, Tom emphasizes the advantages of leveraging existing toolchains and dependencies already built. “There is an ability to have this recipe, and it has a great chance of just working on my computer. If someone has already written the recipes, use them.” In our case, we use Obsidian System’s Obelisk which is already integrated with Nix to handle the difficult task of distributing GHCjs, the Haskell to JavaScript compiler. However, he cautions that careful consideration is required when adopting Nix, as it can both save and cause pain depending on the situation. Tom suggests using Nix in scenarios where reproducible environments are crucial and when there is no existing expertise in Kubernetes (K8S) or Docker.

In terms of Nix and NixOS, Tom explains that he has chosen to use both, depending on the context. For his personal development environment, Nix and NixOS provide an easier way to manage dependencies. For server management, with the goal of aligning development with production environments, NixOS proves invaluable. With Nix, the process of ensuring dev matches prod becomes effortless, requiring no additional thought or effort.

Looking towards the future, Tom aspires to continue using Nix instead of dealing with the complexity and overhead of Kubernetes. Acknowledging the challenges of Kubernetes YAML, he believes that Nix provides a more favorable alternative for managing scalability.