[xpe]

Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems.

With this in mind, the question shifts from rather vague talk about possible futures to various kinds of scenarios.

What happens when software developers have a deterministic build system? On the whole, the benefits are significant. Sure, there are costs to get there. In my view, the benefits often outweigh the costs.

[lelanthran]

> Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems.

I disagree with the whole "highly likely" bit. Just because something new has a large positive value, that does not mean that a large time-investment or effort-investment in it is likely to pay off.

After all, it may never get traction to make the cost of learning it worthwhile - some other, newer, better, easier system could come along and be adopted instead.

We've seen this play out again and again in the technology world[1]. In 2000, a large time and effort investment into UTF-16 would be wasted as the world adopted UTF-8 instead. A large time and effort invested into new languages with powerful features (Haskell, circa 2005) would be wasted as the industry largely ignored it in favour of (presumably) inferior alternatives.

Is nix highly likely to provide solutions to a whole class of problems?

Sure.

Is it highly likely to be the dominant, or even a common tool, in the future that solves those problems?

Doubtful; "easier-to-use" has always won against "can better solve problems". I see no evidence that this will change anytime soon.

[1] I've found that by procrastinating about learning a new technology, I can sometimes manage to avoid having to learn it altogether, because the tech dies off before my procrastination does. By putting off learning VRML in 2001, it went away before I ever got to it.

Likewise, I'll put off learning new things until I actually have a need for the solution they offer. At least then, even if they die out in a few years, I'd have at least solved my immediate problems.

[xpe]

> Likewise, I'll put off learning new things until I actually have a need for the solution they offer. At least then, even if they die out in a few years, I'd have at least solved my immediate problems.

Your choice of language: saying 'need' suggests a black and white decision. See what I mean?

Costs and benefits often cannot be estimated accurately 'in one go'. It is common to spend some time and money to increase understanding and thus reduce uncertainty.

What deterministic build systems have you used? If you have not, how confident should you be that you can accurately assess their costs and benefits?

PS. Your comments suggest to me that, like most people with experience, you have become overconfident. To disabuse yourself of this, I suggest you find a prediction market and make some bets. You'll find you have to make your claims testable. Make a specific prediction/bet on Nix and let's see what happens. Let us know how it goes.

[xpe]

> Is it highly likely to be the dominant, or even a common tool, in the future that solves those problems? Doubtful; "easier-to-use" has always won against "can better solve problems". I see no evidence that this will change anytime soon.

The way you've framed the question is notable. The argument structure ignores a common pattern in software: tools steal ideas from each other often.

For example, MySQL is very different than its 2002 version. There are more database back ends with various guarantees and performance tradeoffs.

[xpe]

> I disagree with the whole "highly likely" bit. Just because something new has a large positive value, that does not mean that a large time-investment or effort-investment in it is likely to pay off.

You are disagreeing with something I didn't write.

[tra3]

Thanks for your thoughts. I worded my question poorly, I suppose, but you got my meaning.

I keep seeing nix mentioned alongside complaints about it's maturity but that seems par for the course for something new, doesn't it? Until a tool reaches critical mass sharp edges are to be expected.

I'll look into nix again when I have an appropriate use case.

[xpe]

The Nix package manager on macOS isn't as smooth as Homebrew. Still, Nix is better in many ways.

More broadly, even if it isn't as popular, Nix is a viable tool and also encourages us (developers) to seek out repeatability in our dependencies.