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!)

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_t....

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.

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.

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 :).

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

> 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.

I feel that. This is one place where the "nix is everything, everything is nix" mentality hurts the project. NixOS modules are where the abstract config option sauce lives. It isn't an inherent part of Nix.

As Nix (and NixOS) becomes more widely used, this is one place where we'll have to find a way to let users do what they know how, and stop getting in the way.

Part of the problem is that the underlying systems aren't Nix, so you're replacing the easy way with the Nix way.

I wouldn't be mad if opening the system preferences and setting my timezone also updated my timezone in Nix. I am mad that I can't change my timezone when I travel, because the GUI picker doesn't know that Nix has taken ownership, so only changes in Nix take effect.

Hell yeah. Speaking my language! I don't know, but we need that!

I mean, it sort of is, on the heals of two other announcements earlier this week:

* https://determinate.systems/posts/announcing-determinate-nix...

* https://determinate.systems/posts/flakehub-cache-and-private...

> So can someone give me elevator pitch that if we are CRUD Web App, why Nix instead of Puppet/Ansible + Docker Containers?

For better or worse, Nix forces you to work out the exact dependency tree of your entire system. It can be a pain but once you have it, if one part of that tree changes, nix can rebuild only and exactly the parts of the system that depend on it. That goes all the way through from packages and libraries to systemd services and application config files. That happens safely, reliably, is extremely cacheable, and is done in a way that can actually be perfectly reverted to a previous version. You can build docker images with nix and the result is very small minimal images (it's effectively a `FROM scratch` every time but with a potentially even better layer structure that again can be more cacheable than a typical Dockerfile setup).

From a security perspective, Nix can be a huge win since it gives you such precise control over what's installed on your system and makes it simple to track, every part of it checks cryptographic hashes, etc. But yeah, most security teams don't know what to do with it yet and probably don't have the tools to deal with it yet.

Hear hear. It takes continuous effort not just on documenting, but also reducing the need for documentation by cutting interfaces and accidental complexity.

I agree that Nix is the right idea, but I'm hesitant to adopt it right now because (i) rough edges like poor documentation and inconsistent interfaces make it feel immature, (ii) things are moving very fast with experimental stuff like flakes, which means it will take a while before Nix starts to stabilize, and (iii) recent community forks like Lix might create a fragmented ecosystem in the long run.

What are your thoughts on there concerns?

I am a Windows user. The default nix implementation does not support Windows.

How can the future of software leave out one of the largest platforms on the planet?

I think guix was just late to the party and the extra steps to setup the nonguix for the non free software like steam is enough of a deterrent for users to go to nix instead.

I use guix myself and prefer its use of scheme. I don't mind having a little less guidance and "how-to" articles available if I'm trying something new because I'm comfortable reading its codebase.

That's what it was for me. I'm really fuzzy on the details because this was years ago. When I first heard about Guix, I wanted to try it (even though I didn't understand the benefits) but there was some unfree part I needed to install it. And ideologically they were against that. There either weren't good tutorials on how to bypass it or it was not even possible. So I just didn't install it.

FWIW Nix does not allow unfree packages by default or, at least, that's what having to add a package to allowUnfreePredicate makes it feel like.

How is Guix's repository? One of Nix's biggest draws (I'd say the biggest) is it's expansive package repository.

...and it never was.

A FlakeHub organization with private flakes and cache is $20/user/month, plus at-cost storage and bandwidth. Members of that organization get automatic access to the private flakes and read access to the cache. In the future, we'll be opening up the policy engine to make it more flexible.

They're great! But also still miss fundamental pieces that Nix gets right. Especially the way the build and dependency graph goes right to the root of every package, and comes together to completely describe the system you're running today.

https://nix.dev/ is pretty good for getting started these days.

Whew. "Everything" is a tough one, today.

1. I know there is an upcoming book, NixOS in Production. There is a lot of great info in there!

2. Have you seen https://zero-to-nix.com/?

Eelco's typical online handle is "niksnut", which obviously means "nix nut" but also "good for nothing" :).

It also means nothing in English, though that's somewhat obscure from my perspective. (Looking it up, it sounds like English borrowed it from German a while back.)

In English I think it's most often used as a verb that means basically to cancel. Like, "We're running out of time, we should nix feature X."

Similarly in English. I think "nix", like "git", is a self-deprecating name. It's a play on both "nix" -- to cancel or to not exist, and "nix" as the suffix for Li- and U-.