4 ms·

The future of software is Nix in the same sense that the future of software was Bitkeeper. It was readily apparent to anyone using Bitkeeper that this was the

The future of software is Nix in the same sense that the future of software was Bitkeeper. It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct. But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from the truth. It has a confusing and awkward language with multiple ways of accomplishing the same task, twisting concepts like "function" and "struct" into confusing knots that make it difficult to follow. Debugging is nearly impossible, and even test evaluations take a lot of work to get right. It is riddled with conventions and "helpers" that have idiomatic forms that are not well-documented and frequently abused. But the model is RIGHT. This is the way to distribute software, this is the way to write software, this is the way to ensure hermetic distributions, this is the way to avoid global implicit state. And Nix as a proof of concept is great because it shows that it does work (basically). So what is the path forward? Kill the language and replace it with configuration, with external scripts to do the heavy lifting. Make mutations of the data model the fundamental operations rather than having an intentional CLI that conceals the underlying functionality. So make it less usable but more understandable (like the path that Git took) and iterate from there.

grhmc 2y ago
Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability. I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).
- adamc 2y ago
  But git had Linus and Linux on board. What is going to give Nix that credibility?
anotherhue 2y ago
I use NixOS in spite of the Nix Language. It's worth it.
- grhmc 2y ago
  My man.
- andrewla 2y ago
  Of course -- as do I. But I've become unwilling to accept that the failure of the Nix language is just a skill issue.
  - deleted 2y ago
    [deleted]
jonringer117 2y ago
There's nothing wrong with the fundamentals of Nix. But working with nixpkgs is quite difficult for most. Which is why I'm attempting to address those issues in a fork, Ekapkgs. The repos will eventually expose optional flake entry points, so it will be compatible with flakes and non-flakes. If you're curious, https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_the_ekala_project_a_nix_inspired/ https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_t....
- grhmc 2y ago
  I love your project, Jon! I think the Nix ecosystem will be improved by having more, smaller things, where the boundaries are clear.
rfoo 2y ago
> Kill the language and replace it with configuration No. Hard no. Please don't tell me you are going to kill a fine (even though awkward) configuration language and replace it with (potentially text-templated) yaml.
- Spivak 2y ago
  I think I would rather replace it with a spec for derivation files implementable in any language that existing build systems can hook into and use as outputs. make derivation python -m build derivation Trying to package software with dependencies that don't exist in nixpkgs is painful despite the tooling existing to build and install them.
  - rfoo 2y ago
    That's an interesting idea. The downside (I could imagine) would be we have to convince people to implement THE RIGHT MODEL in every build tools in the world, but if that's possible then indeed it would work a lot better.
rossng 2y ago
It feels like there might still be time for Nix to morph into something that can get mass adoption. But it probably requires some radical technical changes and the controversy around flakes (which are incredibly useful) suggests that the existing community might not accept that. Whatever comes next, IMO the killer feature will be that it enables rock solid developer tooling. LSPs that work; typed inputs to modules; control of deployment of NixOS machines and so on.
Ferret7446 2y ago
Declarative configuration predates Nix, there are many far more popular options both before and after Nix, and generally declarative configuration is only ever popular/used in a few specific domains/niches. I remember being enamored by Haskell in college and I asked my professor why pure functional languages aren't more popular. His answer really stuck with me. He said: because reality is stateful. Reality is stateful. As a consequence, declarative configuration leaks like a sieve, and leaky abstractions suck. When you think about it, declarative configuration is just a DSL for implementing idempotent deployment flow, and idempotent deployment flows in general are quite successful (e.g., Docker, Flatpak, Ansible), and so declarative configuration tends to work okay for restricted subsets of those domains.
- tome 2y ago
  That's a strange objection, because Haskell supports state, of course. In fact I'd say it's the best language for supporting state, because it makes it explicit.
kylewlacy 2y ago
There are also quite a few attempts at "Nix without NixLang". In the ecosystem, I can think of Nickel (a different configuration language, but one with strong typing), Garn (Nix but using TypeScript), and Guix (Nix but using Scheme, and also kind of an ecosystem fork I think?). The common link behind all of them is that they all still have Nix in their DNA, i.e. using a Nix store with Nix derivations under the hood Outside Nix, there's Brioche (my project!), and there's also Vorpal and Tangram, all of which are "Nix-like" but are from-scratch projects instead of using any Nix tooling So I definitely agree that Nix as an _idea_ is right, and I definitely also agree that NixLang is a blocker for mass adoption. Personally though, I think if you dig deeper, there are other places that could use improvement beyond just the language itself (but nothing that would necessarily be a show-stopper for adoption IMO). But that's why my project is a "Nix-like"-- there are things that I think Nix could / should do, but which aren't really compatible with the way Nix itself works. One example: Brioche works without having a global store path-- it's per-user instead so that it can be installed rootlessly-- which doesn't really map well to how Nix itself handles store paths and dependencies So point is, I agree Nix is the right model, but I think the _real_ gold lies outside Nix itself (...with the side note that I'm obviously biased!)
- andrewla 2y ago
  I’ll check out your project - everything you say here resonates with me, especially the rootless nature. What we probably need, long term, is a content addressable store, local first, secure, and freely shareable. Layering this on top of POSIX filesystems feels awkward and difficult to trust. But this is the fundamental building block of Nix-like systems and would make the move from rootless to system-wide a mostly trivial exercise.
- brianjlogan 2y ago
  That doesn't make sense to me. You can use Nix on non NixOS distros in your user space. Home manager is quite popular. Have you tried using it in user space?

grhmc 2y ago

Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability. I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).

adamc 2y ago
But git had Linus and Linux on board. What is going to give Nix that credibility?

anotherhue 2y ago

I use NixOS in spite of the Nix Language. It's worth it.

grhmc 2y ago
My man.
andrewla 2y ago
Of course -- as do I. But I've become unwilling to accept that the failure of the Nix language is just a skill issue.
- deleted 2y ago
  [deleted]

jonringer117 2y ago

There's nothing wrong with the fundamentals of Nix. But working with nixpkgs is quite difficult for most. Which is why I'm attempting to address those issues in a fork, Ekapkgs. The repos will eventually expose optional flake entry points, so it will be compatible with flakes and non-flakes. If you're curious, https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_the_ekala_project_a_nix_inspired/ https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_t....

grhmc 2y ago
I love your project, Jon! I think the Nix ecosystem will be improved by having more, smaller things, where the boundaries are clear.

rfoo 2y ago

> Kill the language and replace it with configuration No. Hard no. Please don't tell me you are going to kill a fine (even though awkward) configuration language and replace it with (potentially text-templated) yaml.

Spivak 2y ago
I think I would rather replace it with a spec for derivation files implementable in any language that existing build systems can hook into and use as outputs. make derivation python -m build derivation Trying to package software with dependencies that don't exist in nixpkgs is painful despite the tooling existing to build and install them.
- rfoo 2y ago
  That's an interesting idea. The downside (I could imagine) would be we have to convince people to implement THE RIGHT MODEL in every build tools in the world, but if that's possible then indeed it would work a lot better.

rossng 2y ago

It feels like there might still be time for Nix to morph into something that can get mass adoption. But it probably requires some radical technical changes and the controversy around flakes (which are incredibly useful) suggests that the existing community might not accept that. Whatever comes next, IMO the killer feature will be that it enables rock solid developer tooling. LSPs that work; typed inputs to modules; control of deployment of NixOS machines and so on.

Ferret7446 2y ago

Declarative configuration predates Nix, there are many far more popular options both before and after Nix, and generally declarative configuration is only ever popular/used in a few specific domains/niches. I remember being enamored by Haskell in college and I asked my professor why pure functional languages aren't more popular. His answer really stuck with me. He said: because reality is stateful. Reality is stateful. As a consequence, declarative configuration leaks like a sieve, and leaky abstractions suck. When you think about it, declarative configuration is just a DSL for implementing idempotent deployment flow, and idempotent deployment flows in general are quite successful (e.g., Docker, Flatpak, Ansible), and so declarative configuration tends to work okay for restricted subsets of those domains.

tome 2y ago
That's a strange objection, because Haskell supports state, of course. In fact I'd say it's the best language for supporting state, because it makes it explicit.

kylewlacy 2y ago

There are also quite a few attempts at "Nix without NixLang". In the ecosystem, I can think of Nickel (a different configuration language, but one with strong typing), Garn (Nix but using TypeScript), and Guix (Nix but using Scheme, and also kind of an ecosystem fork I think?). The common link behind all of them is that they all still have Nix in their DNA, i.e. using a Nix store with Nix derivations under the hood Outside Nix, there's Brioche (my project!), and there's also Vorpal and Tangram, all of which are "Nix-like" but are from-scratch projects instead of using any Nix tooling So I definitely agree that Nix as an _idea_ is right, and I definitely also agree that NixLang is a blocker for mass adoption. Personally though, I think if you dig deeper, there are other places that could use improvement beyond just the language itself (but nothing that would necessarily be a show-stopper for adoption IMO). But that's why my project is a "Nix-like"-- there are things that I think Nix could / should do, but which aren't really compatible with the way Nix itself works. One example: Brioche works without having a global store path-- it's per-user instead so that it can be installed rootlessly-- which doesn't really map well to how Nix itself handles store paths and dependencies So point is, I agree Nix is the right model, but I think the _real_ gold lies outside Nix itself (...with the side note that I'm obviously biased!)

andrewla 2y ago
I’ll check out your project - everything you say here resonates with me, especially the rootless nature. What we probably need, long term, is a content addressable store, local first, secure, and freely shareable. Layering this on top of POSIX filesystems feels awkward and difficult to trust. But this is the fundamental building block of Nix-like systems and would make the move from rootless to system-wide a mostly trivial exercise.
brianjlogan 2y ago
That doesn't make sense to me. You can use Nix on non NixOS distros in your user space. Home manager is quite popular. Have you tried using it in user space?