Some comments on Nix

Nix is a truly revolutionary approach to package management and system configuration. Its core concepts – a content-addressed store, atomic upgrades and rollbacks, and declarative, reproducible builds – offer a level of control and reliability that’s unmatched by traditional tools. For complex deployments, especially where reproducibility is paramount, Nix can be incredibly powerful, eliminating the “it works on my machine” problem and enabling consistent environments across development, testing, and production.

However, the path to harnessing this power is often fraught with challenges, stemming from design choices that prioritize internal elegance and theoretical purity over user experience. This post discusses some of the most significant hurdles faced by Nix users (esp. newcomers), explores the potential of Guix as an alternative, and considers ways in which Nix itself could evolve to become more accessible.

Despite its current flaws, the fundamental ideas behind Nix remain incredibly valuable, and with focused effort on usability, it could become the de facto standard for reproducible software deployment.

Some issues with Nix

I. Inflexible Core Design Choices

1. Hardcoded /nix/store Path (and macOS Symlink Issues):
   • Criticism: The inability to change the Nix store location from /nix is a significant limitation. This creates problems on systems where /nix is unavailable, impractical, or conflicts with existing setups. The restriction against symlinks on macOS exacerbates this.
   • User-Hostility: Forces users to adapt their system to Nix, rather than the other way around. Limits deployment options and creates unnecessary friction. This is especially problematic for shared systems or systems with strict filesystem policies.
   • Note: cf. https://lists.debian.org/debian-devel/2019/01/msg00010.html (6 years ago) but nothing has changed since.

II. Installer and Deployment Challenges

2. Rejection of Standard Package Management Approaches:

   • Criticism: Nix’s strong preference for its own installer and discouragement (even outright hostility) towards alternative installation methods (like Debian packages) creates an “all-or-nothing” situation. This prevents easier integration with existing systems and workflows.
   • User-Hostility: Isolates Nix from the broader ecosystem of package management tools. Makes it harder to adopt Nix incrementally or use it alongside other tools. Forces users into a specific installation pathway, even if it’s not the best fit for their needs.

3. Proprietary “Better” Installer (Determinate Systems):

   • Criticism: While the Determinate Systems installer improves the Nix installation experience, its proprietary nature raises concerns. A core component of a supposedly open-source project being closed-source creates a conflict of interest and limits community contributions.
   • User-Hostility: Creates a two-tiered system where the “best” experience is locked behind a proprietary solution. This goes against the spirit of open-source software and can create vendor lock-in.

4. Installer UX and Feature Gaps (Even with Improvements):

   • Criticism: Even with the Determinate Systems installer, the overall user experience still lags behind other package managers. Missing features and rough edges persist.
   • User-Hostility: Indicates a lack of polish and attention to detail in the onboarding process. Makes the initial experience more frustrating than necessary.

5. Lack of Official Cloud Images (NixOS):

   • Criticism: The absence of official NixOS images on major cloud providers (AWS, GCP, Azure, Digital Ocean, OVHCloud, Hetzner, Scaleway, etc.) is a major obstacle to automated deployments and cloud adoption. The recommended workarounds are often complex and unsuitable for production environments.
   • User-Hostility: Significantly limits the use of NixOS in cloud environments, a crucial area for modern software development. Forces users to jump through hoops for something that should be readily available.

III. Communication and Community Issues

6. “Read the Nix PhD Thesis” Culture:
   • Criticism: The frequent referral to the Nix PhD thesis (or complex academic papers) as a solution to simple user problems creates an exclusionary atmosphere. It implies that a deep academic understanding (e.g. graduate level) is required to use Nix effectively.
   • User-Hostility: Discourages newcomers and creates a perception that Nix is only for experts. Fails to provide accessible solutions for common problems. Prioritizes theoretical purity over practical usability.
   • 7. Community Focus on Technical Users:
   • Criticism: The Nix community is largely composed of highly technical users, often developers themselves. This creates an environment where solutions and discussions often assume a high level of expertise, making it less welcoming to newcomers or those with less technical backgrounds.
   • User-Hostility: Excludes users who aren’t already deeply familiar with both systems programming and functional programming concepts. Makes it harder to find accessible solutions to common problems.

IV. The Nix Language and Ecosystem

7. Steep Learning Curve:

   • Criticism: The Nix language remains a major barrier to entry. Its functional, lazy nature, and lack of a comprehensive standard library make it difficult to learn and use, even for experienced developers. The multiple entry points (nix-env, Flakes, etc.) further complicate matters.
   • User-Hostility: Forces users to invest significant time and effort in learning a niche language, even for basic package management tasks. The lack of readily available, easy-to-understand resources exacerbates this.

8. Cryptic Error Messages:

   • Criticism: Nix error messages are often unhelpful, pointing to internal Nixpkgs code rather than the user’s mistake. This makes debugging extremely difficult, especially for newcomers.
   • User-Hostility: Wastes user time and creates frustration. Makes it hard to learn from mistakes and improve one’s understanding of Nix.

9. Binary Cache Complexity:

   • Criticism: While binary caches are essential for reasonable build times, setting them up and using them effectively (especially with custom derivations) can be complicated and poorly documented.
   • User-Hostility: Long build times without a properly configured binary cache hinder productivity and make Nix feel slow and cumbersome, at a time when sub-second updates (with Vite for JS applications, or uv for Python packages…) is now the norm.

10. Immutability Challenges:

    • Criticism: While beneficial for reproducibility, the strict immutability makes simple modifications or patching of packages unnecessarily complex, requiring users to understand and write Nix expressions.
    • User-Hostility: Adds significant overhead to workflows that are straightforward in other package managers

11. User-Hostile Defaults (Flakes):

    • Criticism: Flakes, widely promoted as the modern and recommended way to use Nix, are not enabled by default. This requires users to manually enable an experimental feature that is presented as the “correct” approach. This creates confusion and inconsistency.
    • User-Hostility: Forces users to discover and enable a crucial feature through out-of-band channels (documentation, blog posts, etc.). Creates a disconnect between the advertised best practices and the default behavior. This is a significant onboarding hurdle.

• 12. Too Many Ways to Do the Same Thing (Major Point):
  13. Criticism: Nix offers a bewildering array of choices for accomplishing even basic tasks. The combination of Flakes vs. non-Flakes, nix-env vs. nix develop vs. nix-shell, home-manager vs. direct configuration, various installers, and the possibility of custom overlays creates a combinatorial explosion of possible configurations. This makes it extremely difficult to find definitive answers or confidently apply solutions found online.
  14. User-Hostility: Creates massive cognitive overhead. Forces users to understand the nuances of many different approaches, even for simple tasks. Makes it impossible to rely on copy/pasting solutions without understanding the specific context in which they were created.

13. Variability of Supported Packages (Quality Over Quantity):
    • Criticism: While Nixpkgs boasts a large number of packages, the quality of Nix integration varies dramatically. Some packages have extensive, well-documented configuration options, while others are minimally integrated, requiring manual setup or custom Nix code.
    • User-Hostility: Creates an inconsistent user experience. Forces users to learn not only Nix, but also the underlying configuration mechanisms of many different applications. Makes it difficult to predict how much effort will be required to integrate a new package.

• 14. Granular Package Control Difficulties:
  15. Criticism: Pinning specific package versions (requiring whole-repository snapshots) and upgrading individual packages are significantly more cumbersome in Nix than in traditional package managers.
  16. User-Hostility: Adds friction to common package management tasks. Makes it harder to manage dependencies and maintain a stable system.

13. Space, Bandwidth, and Resource Use:
    • Criticism: Nix’s hermetic nature leads to large downloads, significant disk space consumption, and occasional heavy CPU load during builds.
    • User-Hostility: Can be impractical for systems with limited bandwidth, storage, or processing power. Creates unexpected performance bottlenecks.

• 14. Difficulties Using New Tech:
  15. Criticism: Trying out new software that isn’t already packaged for Nix often requires significant effort, such as creating a nix-shell or writing a custom derivation.
  16. User-Hostility: Discourages experimentation and rapid prototyping. Creates a barrier to adopting new tools and technologies.
• 15. Messy Configs (and the “Nix Tax”):
  16. Criticism: Nix configurations often become cluttered with notes, commented-out attempts, and complex workarounds, reflecting the ongoing effort required to maintain a working setup. The “Nix tax” refers to the extra time and effort needed to integrate everything with Nix.
  17. User-Hostility: Makes configurations harder to understand and maintain. Increases the cognitive burden on users.
• 16. Development Environment Challenges:
  17. Criticism: Setting up and using development environments with Nix, even with tools like devenv, can be complex and frustrating. Issues include the need to “shell into shells,” difficult IDE integration, and the need to Nixify every aspect of the development workflow.
  18. User-Hostility: Adds significant overhead to development workflows. Makes it harder to collaborate with developers who aren’t using Nix. Can disrupt established workflows.

13. Legacy Cruft:
    • Criticism: Remnants of older systems and approaches within Nix (like the misleading package search results in nix-darwin) can create confusion and frustration for users.
    • User-Hostility: Undermines trust in the system and makes it harder to find reliable information.

Okay, let’s expand “Numerous Real-world Examples” into a more detailed section, drawing from the provided blog post and structuring it to clearly illustrate how seemingly basic tasks often become unexpectedly complex in Nix. We’ll break it down by category and highlight the specific user-hostility in each case.

V. Numerous Real-World Examples: The Breakdown of Basic Functionality:

The following examples, drawn from real user experiences (e.g. https://www.dgt.is/blog/2025-01-10-nix-death-by-a-thousand-cuts/), demonstrate how seemingly simple, everyday tasks that are taken for granted in other operating systems or package managers often require significant effort, troubleshooting, and workarounds in Nix. This constant friction makes Nix challenging for daily use, especially for users who expect a smooth and predictable experience.

• Desktop Environment Integration:

  • Problem: Standard desktop application integration (e.g., having newly installed applications appear in the application launcher) is unreliable. This basic functionality, expected to “just work,” often requires logging out, rebooting, or switching between Wayland and Xorg. Even then, success isn’t guaranteed.
  • User-Hostility: Breaks the fundamental expectation of a modern desktop environment. Makes it frustrating to install and use new software. Undermines the user’s confidence in the system.
  • Example: Installing a Flatpak application (even using Nix’s official Flatpak support) might not result in the application appearing in the launcher until after multiple restarts, or it might not appear at all. Bug reports related to this issue remain unresolved.
  • Problem: Using both Gnome and KDE is not supported “out of the box”.
  • User-Hostility: Should be possible to easily switch.

• ZFS Setup:

  • Problem: Setting up encrypted root with ZFS, a common and desirable configuration, is not straightforward. The official documentation points users to outdated, unmaintained, personal repositories rather than providing a clear, supported solution.
  • User-Hostility: Forces users to rely on unofficial, potentially unreliable resources for a critical system configuration. Creates uncertainty and risk. Demonstrates a lack of attention to common use cases.
  • Example: The recommended approach involves downloading a setup from a personal Git repository, which later disappeared, leaving users stranded.

• Symbolic Links (and npm link):

  • Problem: Nix’s emphasis on immutability and its content-addressed store clashes with the traditional Unix use of symbolic links. While symlinks are sometimes necessary for interoperability with non-Nix tools or for specific development workflows (like npm link in Node.js development), Nix makes using them difficult and often requires “impure” workarounds.
  • User-Hostility: Forces users to choose between adhering to Nix’s purity and using common Unix tools and workflows. Creates friction for developers who rely on symlinks.
  • Example: Using npm link to manage dependencies in a monorepo project fails due to Nix’s restrictions on symlinks, requiring the developer to find alternative (and potentially less convenient) solutions.

• Conda Environments:

  • Problem: Integrating Conda, a popular package manager for Python and other languages, with Nix is surprisingly complex. The official Nix documentation provides limited guidance, and community solutions are fragmented and inconsistent. This leads to a multi-layered shell environment (Nix shell, conda shell, conda environment) that is cumbersome to manage.
  • User-Hostility: Makes it difficult to use a widely adopted tool within the Nix ecosystem. Adds significant overhead to development workflows. Highlights the difficulty of integrating with external tools.
  • Example: A typical workflow involves multiple levels of shell nesting, making it difficult to integrate with IDEs and requiring a complex series of commands just to start working on a project. The “official” derivation is outdated, requiring additional user intervention.

• Syncthing (User Services and State):

  • Problem: While the basic Syncthing setup in Nix is relatively straightforward, managing Syncthing as a user service (via home-manager) and ensuring persistent state across restarts can be problematic. Options are lacking, and users may need to create their own XML configurations.
  • User-Hostility: Illustrates the challenges of managing user-level services and configurations within Nix. Highlights the inconsistencies between different parts of the Nix ecosystem.
  • Example: Syncthing might repeatedly ask to add the same shares after every restart, despite being configured correctly, indicating problems with state management.

• Distrobox and Flatpak (Escape Hatches That Fail):

  • Problem: Even when using “escape hatches” like Distrobox (to run other Linux distributions within Nix) or Flatpak (for containerized applications), users encounter unexpected issues and limitations. These tools, intended to provide compatibility and flexibility, often fail to work reliably within the Nix environment.
  • User-Hostility: Undermines the promise of these tools as solutions to Nix’s limitations. Creates further frustration and reinforces the feeling that Nix is an “all-or-nothing” system.
  • Example: Distrobox might hang when starting or updating a container, leaving the user with no clear way to troubleshoot. Flatpak installations might take an excessively long time or fail silently, and manually installed Flatpaks may not be properly contained.

• General Theme: These examples share a common thread: they demonstrate how Nix’s unique approach, while theoretically sound, often creates practical difficulties in everyday usage. What should be simple and seamless becomes complex and fragile. This constant friction erodes user trust and makes Nix feel unsuitable for daily use, despite its potential benefits. The “Nix tax” is pervasive, requiring users to invest significant time and effort in overcoming seemingly minor obstacles.

Is Guix a solution?

Guix is a solution, but whether it’s the solution for you depends heavily on your specific needs, priorities, and tolerance for a similar (but distinct) set of challenges. It’s best to think of Guix as a close relative of Nix, sharing many of the same foundational ideas but with different design choices and trade-offs. Here’s a breakdown:

How Guix Addresses Nix’s Criticisms (and Where it Doesn’t):

• Hardcoded /nix/store Path: Guix solves this. By default, it uses /gnu/store, but crucially, this is configurable. You can change the store location, and Guix fully supports this. This is a major win.

• Rejection of Standard Package Management Approaches: Guix is more integrated with the GNU ecosystem and, in some ways, more “traditional.” It uses Guile Scheme (a well-established language) and has a more familiar package definition structure. However, it’s still fundamentally different from traditional package managers like apt or yum. It’s not a drop-in replacement, but the learning curve might be slightly less steep if you already know Scheme.

• Proprietary “Better” Installer: Guix is entirely free software, under the GPL. There’s no proprietary installer equivalent to Determinate Systems. The Guix System installer is straightforward, text-based, and fully open.

• Installer UX and Feature Gaps: The Guix System installer is generally considered good, although it’s text-based, which might not appeal to everyone. It’s functional and gets the job done, but it’s not as visually polished as some graphical installers.

• Lack of Official Cloud Images: Guix does have official images for several cloud providers (including AWS, GCE, and others), and there are community-maintained images as well. This is a significant advantage over NixOS in terms of ease of deployment in the cloud.

• “Read the Nix PhD Thesis” Culture: The Guix community is generally considered to be welcoming and helpful. While you’ll still need to learn the concepts, the documentation is often cited as being better structured and more accessible than Nix’s (historically, at least). The emphasis on Guile Scheme also means there are more general-purpose resources available for learning the language.

• Steep Learning Curve: Guix still has a learning curve, but it’s arguably less steep than Nix’s.

  • Guile Scheme: Using Guile Scheme (a dialect of Scheme) as the configuration language is a significant difference. Scheme is a well-established language with a long history and plenty of learning resources. If you have any experience with Lisp-like languages, the transition will be much easier. If not, it’s still a functional language, which requires a different way of thinking.
  • Package Definitions: Guix package definitions are generally considered more readable and easier to understand than Nix expressions, especially for simple cases. They are also written in Scheme.
  • Fewer Entry Points: Guix has a more unified approach than Nix, with fewer competing ways to do the same thing. This reduces confusion for beginners.

• Cryptic Error Messages: Guix’s error messages are generally better than Nix’s, but they can still be challenging at times. Debugging still requires understanding the system.

• Binary Cache Complexity: Guix has a good binary substitution system (similar to Nix’s binary caches). The official Guix build farm provides pre-built binaries for many packages, and setting up your own binary cache is relatively straightforward.

• Immutability Challenges: This is a shared characteristic. Like Nix, Guix prioritizes immutability. Making modifications to packages still requires understanding the build process and writing (Scheme) code, but the process is often considered slightly simpler in Guix.

Guix’s Own Potential Drawbacks:

• Smaller Package Collection: Guix has a smaller package collection than Nixpkgs. While it covers most common software, you might find that some niche packages are missing.
• GNU Ecosystem Focus: Guix is strongly tied to the GNU project and its philosophy. This means it prioritizes free software and may not include non-free packages (e.g., proprietary drivers) by default. (There are non-free channels, but they’re not officially supported.) Unlike Nix, it doesn’t work on MacOS. This is a philosophical choice that may be a pro or a con depending on your perspective.
• Less Popular: Guix has a smaller community and user base than Nix. This means fewer online resources, tutorials, and community support.
• Guile Scheme: While Scheme is a well-established language, it’s less popular than many other languages. Finding developers with Scheme experience might be more challenging than finding developers familiar with, say, Python or JavaScript.

In Summary: Is Guix a Solution?

Guix directly addresses many of the most common criticisms of Nix, particularly regarding:

• Store Path Flexibility: A major win.
• Installer: A solid, open-source installer.
• Cloud Deployment: Official cloud images are available.
• Language: Guile Scheme is arguably more approachable than the Nix language.
• Documentation: Generally considered better.
• Community: Welcoming and helpful.

However, Guix is not a perfect drop-in replacement for Nix. It has its own learning curve, a smaller package collection, and a strong commitment to free software.

Recommendation:

• If you’re completely new to both Nix and Guix, and the criticisms of Nix are major deterrents, Guix is definitely worth considering. It’s likely to be a less frustrating experience overall.
• If you’re already invested in Nix and have overcome the initial learning curve, switching to Guix might not be worth the effort unless you’re specifically facing issues that Guix solves (like the /nix/store limitation).
• If you need a very wide range of packages, including non-free software, Nixpkgs (with its larger collection) might be a better choice, despite its drawbacks.
• If you value free software and the GNU philosophy, Guix is a natural fit.

The way forward?

Fixing Nix and its ecosystem is a multifaceted challenge, requiring improvements across several key areas. It’s not about abandoning the core principles that make Nix powerful (reproducibility, declarative configuration), but about making it more accessible, user-friendly, and maintainable. Here’s a breakdown of potential solutions, categorized for clarity:

I. Core Nix (The Engine and Language)

1. Rethink the Nix Language (Long-Term):

   • Option A: Gradual Evolution: Incrementally improve the existing Nix language. This would involve adding features for better error handling, debugging, and modularity. A standard library is essential. Improving type checking and providing more informative error messages are crucial short-term goals.
   • Option B: New Language (Radical): Explore a new language designed specifically for Nix’s needs, but with usability as a primary concern. This could be a more constrained language built on top of a well-known base (e.g., a subset of Python or a dedicated DSL). This is a huge undertaking, but could address many of the fundamental usability issues.
   • Key Principle: Prioritize discoverability and learnability. The language should be intuitive, with clear syntax and helpful error messages. It should be possible to accomplish common tasks without needing a deep understanding of functional programming concepts.

2. Improve Error Messages (Immediate Priority):

   • Action: Focus on providing clear, concise, and actionable error messages. Instead of pointing to deep within Nixpkgs, error messages should pinpoint the user’s error and suggest possible solutions. This requires significant engineering effort to improve error reporting throughout the Nix codebase.
   • Example: Instead of “error: infinite recursion encountered,” provide the specific location in the user’s code where the recursion occurred and suggest potential causes (e.g., a missing base case in a recursive function).

3. Configurable Store Path (Already Addressed, but Needs Wider Adoption):

   • Action: While technically possible with hacks, Nix needs first-class support for a configurable store path. This should be a simple, well-documented setting. The macOS symlink issue needs a proper solution.
   • Impact: Removes a major barrier to adoption on systems with non-standard file system layouts.

4. Standardize on Flakes (with Backward Compatibility):

   • Action: Make Flakes the official, recommended way to use Nix. Provide clear migration paths from older approaches (nix-env). Continue to improve Flakes’ stability and usability. However, maintain some level of backward compatibility to avoid breaking existing workflows.
   • Impact: Reduces confusion for newcomers and provides a more consistent user experience.

II. Nixpkgs (The Package Repository)

5. Improve Package Maintainability:

   • Action: Establish clearer guidelines and tooling for package maintainers. Encourage code reuse and modularity to reduce duplication and improve consistency. Automated testing and linting are essential.
   • Impact: Makes Nixpkgs more robust, easier to contribute to, and less prone to breakage.

6. Binary Cache Improvements:

   • Action: Simplify the process of setting up and using binary caches, both public and private. Provide better documentation and tooling for managing caches. Explore ways to make binary substitution more reliable and efficient.
   • Impact: Reduces build times, making Nix faster and more convenient.

7. Better Handling of Non-Free Software:

   • Action: Provide a clear, official, and well-documented way to include non-free software (e.g., proprietary drivers or applications) in Nix builds, without compromising the integrity of the free software components. The current allowUnfree is a good start, but needs improved documentation, user experience, and possibly finer-grained control.
   • Impact: Makes Nix more practical for users who need non-free software.

III. Documentation and Learning Resources

8. Revamp the Official Documentation (High Priority):

   • Action: Rewrite the official documentation from the ground up, focusing on clarity, completeness, and user-friendliness. Provide clear tutorials, examples, and troubleshooting guides. Organize the documentation logically and make it easy to search. A “cookbook” approach with common recipes would be very helpful.
   • Impact: Makes Nix much more accessible to newcomers and reduces the reliance on scattered blog posts and forum threads.

9. Create a “Nix for Humans” Guide:

   • Action: Develop a comprehensive, beginner-friendly guide that focuses on practical usage and avoids overwhelming users with technical details. This guide should cover common tasks, best practices, and troubleshooting tips.
   • Impact: Provides a gentler introduction to Nix and helps users get started quickly.

10. Develop Interactive Tutorials:

    • Action: Create interactive tutorials or online courses that allow users to learn Nix by doing. These could be integrated into the official documentation or offered as separate resources.
    • Impact: Provides a more engaging and effective learning experience.

IV. Community and Communication

11. Foster a More Welcoming Community:

    • Action: Encourage a culture of inclusivity and helpfulness in the Nix community. Discourage elitism and the “RTFM” attitude. Provide clear channels for asking questions and getting support.
    • Impact: Makes Nix more approachable and less intimidating for newcomers.

12. Improve Support Channels:

    • Action: Consolidate and improve the official support channels (e.g., forums, chat rooms). Ensure that questions are answered promptly and accurately. Consider creating a dedicated support team or community moderators.
    • Impact: Provides better support for users and reduces frustration.

13. Promote Best Practices:

    • Action: Clearly document and promote best practices for using Nix, writing Nix expressions, and contributing to Nixpkgs.
    • Impact: Improves the overall quality and consistency of the Nix ecosystem.

V. Tooling and Ecosystem

14. Develop Better Tooling:

    • Action: Invest in developing better tools for working with Nix, such as:
      • Debuggers: A proper debugger for Nix expressions is essential.
      • Linters: Linters to check for common errors and style issues.
      • Package Management GUIs: Graphical user interfaces for managing packages and environments.
      • IDE Integration: Better integration with popular IDEs and text editors.
    • Impact: Makes Nix easier to use and more productive.

15. Official Cloud Images (Already Addressed, but Needs Continued Effort):

    • Action: Maintain and update official NixOS images for all major cloud providers. Make the process of deploying NixOS in the cloud as seamless as possible.
    • Impact: Facilitates cloud adoption and automated deployments.

VI. Governance and Project Management

16. Establish Clear Governance:

    • Action: Define a clear governance structure for the Nix project, with well-defined roles and responsibilities. This will help ensure that decisions are made in a transparent and accountable manner.
    • Impact: Improves the long-term sustainability and stability of the project.

17. Prioritize User Experience:

    • Action: Make user experience a central consideration in all design and development decisions. This requires actively soliciting and incorporating user feedback.
    • Impact: Shifts the focus from purely technical considerations to the needs of real users.

These changes require a significant, coordinated effort from the Nix community and core developers. Some are short-term fixes, while others are long-term projects. The key is to acknowledge the usability issues and prioritize making Nix more accessible to a wider audience without sacrificing its core strengths. A gradual, iterative approach, with a strong focus on user feedback, is likely to be the most successful path.

Alternative approaches

You’re right, sometimes incremental improvements aren’t enough. A fresh start, building on the core ideas of Nix but prioritizing usability from day one, is a compelling thought experiment. Here are several alternative approaches, ranging from evolutionary to revolutionary, and the trade-offs involved:

1. The “Nix-Inspired DSL” Approach (Evolutionary)

• Concept: Keep the core concepts of Nix: content-addressed store, atomic upgrades/rollbacks, declarative configuration, and reproducibility. However, replace the Nix language with a custom-designed Domain-Specific Language (DSL) built on top of a popular, well-understood language (e.g., Python, Rust, a restricted subset of JavaScript, or even a well-designed YAML/JSON-based format with extensions).
• Key Features:
  • Familiar Syntax: Leverage the syntax and idioms of the underlying language. If it’s Python-based, it should feel like Python.
  • Strong Typing: Provide robust static typing to catch errors early.
  • Excellent Error Messages: Prioritize clear, actionable error messages that point directly to the user’s mistake.
  • Built-in Tooling: Include a linter, formatter, debugger, and REPL (Read-Eval-Print Loop) from the start.
  • Standard Library: A comprehensive, well-documented standard library for common tasks.
  • Implicit Build Context: Avoid the need for explicit pkgs arguments everywhere. The build context should be implicitly available.
  • Simplified Overlays/Overrides: Make it easy to customize existing packages without requiring deep knowledge of the underlying build process. A more intuitive system than Nix’s overlays.
  • First-Class Binary Caching: Integrate binary caching seamlessly into the core workflow.
  • Configurable Store Location: Built-in from the start.
• Pros:
  • Lower learning curve for developers familiar with the underlying language.
  • Leverages existing tooling and ecosystems.
  • Easier to integrate with other systems.
  • Potentially faster development due to using an existing language.
• Cons:
  • Might not be as expressive or flexible as the Nix language for very complex configurations.
  • Still requires designing a good DSL, which is a non-trivial task.
  • Dependencies on the underlying language’s ecosystem.

2. The “Package Manager as a Library” Approach (More Radical)

• Concept: Instead of a monolithic package manager with its own language, create a library (in a language like Rust, Go, or Python) that provides the core functionality of Nix: building derivations, managing the store, performing atomic updates, etc. This library could then be used to build various front-ends: a command-line interface, a GUI, a web interface, etc.
• Key Features:
  • API-First Design: The primary interface is a well-documented API.
  • Embeddable: Can be easily integrated into other applications and workflows.
  • Multiple Front-Ends: Allows for different user interfaces tailored to specific needs.
  • Language Agnostic: The library can be used from any language that can call into it (via FFI or bindings).
  • Focus on Core Functionality: The library provides the building blocks; higher-level abstractions (like package definitions) can be built on top.
• Pros:
  • Maximum flexibility and customizability.
  • Enables a wider range of use cases beyond traditional package management.
  • Avoids the “walled garden” effect of Nix.
  • Potentially better performance due to being implemented in a lower-level language.
• Cons:
  • Requires more effort to build a complete user experience (since you’re starting with just a library).
  • Might be less accessible to non-programmers.
  • Risk of fragmentation if different front-ends are developed without coordination.

3. The “Declarative Container-Based” Approach (Different Paradigm)

• Concept: Combine the ideas of declarative configuration and containerization. Instead of building packages from source in a content-addressed store, use pre-built container images (e.g., Docker images) as the fundamental building blocks. A configuration file (in a user-friendly format like YAML or a simple DSL) would describe how to compose these images into a complete system.
• Key Features:
  • Image-Based: Relies on existing container image registries (Docker Hub, etc.).
  • Declarative Composition: Define system configurations by composing images.
  • Reproducibility (via Image Digests): Use image digests (not tags) to ensure reproducibility.
  • Atomic Updates/Rollbacks: Leverage container image layering for atomic updates.
  • Simplified Dependency Management: Dependencies are managed within the container images themselves.
  • Sandboxing: Containers provide inherent isolation and security.
• Pros:
  • Potentially faster builds (since you’re using pre-built images).
  • Leverages the existing container ecosystem.
  • Easier to understand for users familiar with containers.
  • Simplified dependency management.
• Cons:
  • Less control over the build process (you’re relying on pre-built images).
  • Potential for image bloat (if images aren’t carefully constructed).
  • Security concerns related to trusting image providers.
  • Might not be suitable for all use cases (e.g., building custom kernels or low-level system components).

4. The “Functional Build System” Approach (Closer to Nix, but Simpler)

• Concept: A build system that embraces functional programming principles, but with a simpler, more approachable language and better tooling. This is closer to Nix than the other approaches, but aims for a significantly reduced learning curve.
• Key Features:
  • Simplified Functional Language: A language designed for expressing build dependencies and transformations, but without the full complexity of the Nix language. Could be based on a well-known functional language (like a subset of Haskell or OCaml) or a new, purpose-built language.
  • Strong Emphasis on Tooling: A robust build system with excellent error reporting, debugging capabilities, and integration with IDEs.
  • Content-Addressed Store: Retain the core concept of a content-addressed store for reproducibility.
  • First-Class Caching: Built-in support for caching build artifacts.
• Pros:
  • Retains the benefits of functional builds (reproducibility, purity).
  • Potentially lower learning curve than Nix.
  • Better tooling and developer experience.
• Cons:
  • Still requires learning a functional language.
  • Might not be as flexible as Nix for very complex build scenarios.

Key Considerations for Any Alternative:

• Community: Building a new system requires building a new community. This is a significant undertaking.
• Migration: How will users migrate from existing systems (Nix, other package managers)?
• Interoperability: Can the new system interoperate with existing tools and ecosystems?
• Sustainability: How will the project be maintained and funded in the long term?

In conclusion, there are many ways to reimagine the core ideas of Nix with a focus on usability. The best approach depends on the specific goals and trade-offs you’re willing to make. A more evolutionary approach (like the Nix-inspired DSL) might be easier to adopt, while a more radical approach (like the “Package Manager as a Library”) offers greater flexibility but requires more upfront investment. The container-based approach offers a different paradigm that leverages existing infrastructure, but at the cost of some control. The “Functional Build System” attempts to retain the core benefits of Nix with a reduced complexity.

References

• https://lwn.net/Articles/962788/ “A look at Nix and Guix” (2024)
• https://www.dgt.is/blog/2025-01-10-nix-death-by-a-thousand-cuts/ “Nix - Death by a thousand cuts” (2025)
  • The author, a seasoned software engineer with extensive Linux experience, details their two-year journey using NixOS as their primary operating system. They praise Nix’s declarative configuration, reproducibility, easy service management, and ephemeral development shells. However, they ultimately conclude that NixOS, in its current state (2025), is not recommended for desktop use, even for experienced Linux users. The author highlights issues such as the complexity of the Nix language, inconsistent package quality and documentation, resource usage, and a fragmented workflow due to multiple ways of achieving the same task. They also describe numerous specific problems encountered with desktop integration, ZFS setup, symbolic links, development tools like npm and Conda, and various applications. Despite appreciating Nix’s potential and the helpful community, the author decides to scale back their NixOS usage, citing the constant need for troubleshooting and the feeling of being stuck in “Nix Purgatory” – aware of Nix’s benefits but burdened by its complexities.
• https://news.ycombinator.com/item?id=42666851 HN comments on the previous post

Page last modified: 2025-03-08 09:43:42