Flakes has an unfortunate past [1]. The fact that so many people are using Flakes now and treating them as stable makes it effectively impossible to make drastic changes, even though the design is flawed in many ways [2]. Nevertheless, the Nix team is discussing the stabilisation in recent weeks, with the tendency to not make breaking changes, but improving the design in the long term.

[1]: https://nix.dev/concepts/faq#why-are-flakes-controversial [2]: https://discourse.nixos.org/t/experimental-does-not-mean-uns...

For some more context: Flawed as they are, Flakes solve a large number of problems Nix experiences without them. This is why I, and presumably many others, use them even in their current experimental state.

An RFC was recently accepted to commit to forming a plan towards stabilization of Flakes: https://github.com/NixOS/rfcs/pull/136

Personally, I don't believe there won't be any breaking changes, but I also believe that the stabilization of Flakes is still a ways away and hope that there will be a reasonable migration path.

I sometimes just hope a new Nix but rewritten from scratch according to 2020s best practices instead of 2000s comes before too long.

With a transpiler to convert Nix to whatever it uses. Nickel?

Maybe I'm dreaming, but a nix-alike built on CUE would be fire.

I spent half of last week trying to make productive use of Nickel, and it's just... not a very fun experience.

Maybe it'll be better someday? We can hope. It's certainly incomplete right now, and the documentation is mostly nonexistent, but I don't think my use-case (incrementally replacing Nix) is supported at all.

All I really want is the Guix api ontop of nixpkgs packages.

And here I want GNU Guix but with an ML language instead of LISP :)

At some point, my developer intuition says we'll get something with the core good ideas of Nix, but simplified.

The problem is that implementation of these ideas is fairly hideously complex for the intelligences of most current humans, and that simplifying that complexity requires even MORE intelligence (or more years of more people staring at the problem until the simpler picture becomes clearer).

That's half the argument for Guix, and the same train of thought that led me to Mercurial back in the 2000's.

For better or worse, Nix has owned the zeitgeist for several years now, and I'd be surprised to see it dethroned before the next paradigm shift.

I find Guix to be much easier to use. Simpler syntax, and it feels like there's more emphasis on being user-friendly. If enough people switched and helped with packaging, there would be basically no downsides. (a big "if", of course)

What I heard Eelco say in a recent conference is that 'nix build' will work with 'old flakes' but as soon as you do a 'nix flake update ' you might have to adapt your flake to the new conventions.

> flake.nix is not written in Nix

Well, how did I not even realize that until now? Wow. An out-loud "holy shit" was hearable over here as I learned THAT one.

Yes, it's basically a ready feature that's not currently the default