Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of software is Nix

determinate.systems

Post reply on HN
Print view View original

21–30 of 64 posts

Re: The future of software is Nix

#21

Post by grhmc »

andrewla wrote: post #12

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 th…

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

Re: The future of software is Nix

#22

Post by nalzok »

grhmc wrote: post #2

Hey folks CEO of Determinate Systems, and the author of the blog post. I'd be glad to answer questions about the post and what we're doing!

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?

Re: The future of software is Nix

#23

Post by abdullahkhalids »

> To make a smooth path from “Nix could solve my dev, build, and configuration management problems” to “Nix is solving these problems” and in a way that doesn’t involve turning someone from a developer to “the Nix person.”

When do we get Nix easy enough for not just software engineers, but also scientists etc who need reliable reproducible systems for running simulations with zero hassle?

Re: The future of software is Nix

#24

Post by grhmc »

nalzok wrote: post #22
grhmc wrote: post #2

Hey folks CEO of Determinate Systems, and the author of the blog post. I'd be glad to answer questions about the post and what we're doing!

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 th…

I think those are fair perceptions and concerns.

Regarding experimental features like flakes: the reality is they're incredibly stable. I've written about this before: https://determinate.systems/posts/experimental-does-not-mean.... They haven't realistically changed in years, because they work so well. The experimental label is practically FUD at this point.

If the Nix team were to change flakes in a breaking way, it would be stunning neglect for the vast, vast percentage of the ecosystem that has already adopted them. Our data shows that of all the (OSS) repositories created every day, almost 90% of them start with a flake.nix. Of all of those projects, less than 20% use the legacy file formats, and most of those are using the flake-compat library.

On documentation and interfaces, I agree, and we and the greater community are working hard to on that problem. I'll take time, but it is decidedly better than it was a few short years ago.

And on community fragmentation, I just don't see it becoming a problem. The core Nix ecosystem is so large and diverse, I don't see meaningful fragmentation coming out of this.

Re: The future of software is Nix

#25

Post by grhmc »

abdullahkhalids wrote: post #23

> To make a smooth path from “Nix could solve my dev, build, and configuration management problems” to “Nix is solving these problems” and in a way that doesn’t involve turning someone from a developer to “the Nix person.” When do we get Nix easy enough for not just software engineers, but also scientists etc who need reliable reproducible systems for running simulations with zero hassle?

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

Re: The future of software is Nix

#27

Post by anotherhue »

andrewla wrote: post #12

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 th…

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

Re: The future of software is Nix

#28

Post by jonringer117 »

andrewla wrote: post #12

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 th…

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

Re: The future of software is Nix

#29

Post by grhmc »

jonringer117 wrote: post #28
andrewla wrote: post #12

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 th…

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

I love your project, Jon! I think the Nix ecosystem will be improved by having more, smaller things, where the boundaries are clear.
Post reply on HN