[aredox]

The main reason for the persistence of Nix despite its warts and general mess is just "first-mover advantage": it was the first, therefore it has more libraries/packages/development of the ecosystem than the alternatives.

Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.

*For example, why are Haskellians using Nix so much instead of integrating its concepts into their own tooling?

[ParetoOptimal]

Cabal has had nix-style local builds since 2016:

https://blog.ezyang.com/2016/05/announcing-cabal-new-build-n...

https://cabal.readthedocs.io/en/2.0/nix-local-build-overview...

Also cabal isn't positioned to be a system level package manager. Haskell programmers are the type to want both their application builds and system dependencies to be reproducible and predictable.

> Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.

Getting Guix packages to be as complete as nixpkgs isn't a matter of laziness though. One person wouldn't be able to do it no matter how disciplined they were.

[karma_pharmer]

Cabal has had nix-style local builds since 2016:

That's a bug not a feature.

Every language these days is trying to force you to use its own badly-implemented imitation of Nix. Just look at what cargo does with the target/ directory and wonky "build fingerprints".

It's madness.

[mikepurvis]

It can also make those systems considerably harder to integrate into Nix itself. There almost need to be some language-neutral standards developed for how to manage inputs and lockfiles in such a way that more of this tooling can be shared at the developer/workspace level while also hoisting the same metadata up into systems like Nix and Bazel.

As it is, the rust-in-Nix and bazel-in-Nix stories are both pretty terrible, while the Python one is actually not too bad: https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/over... and these 27000 lines of telling Nix which Python buildsystem every package ever happens to use: https://github.com/nix-community/poetry2nix/blob/master/over...)

[Macha]

You'll also need to deal with project philosophy regarding closed source packages to get Guix as streamlined as Nix.

[karma_pharmer]

Guix or any rewrite as a library in a well-developed language

The fundamental difference with Guix is that evaluation (what they call "host code" -- everything that happens BEFORE the .drv is written) is wildly impure.

Guile code can access the network, write to the filesystem, heck it can even pull bytes from /dev/random. It can delete your home directory or email your ssh private keys to Zimbabwe.

The Nix language, by contrast, is incredibly restricted in order to make evaluation a deterministic function of the .nix source code you give it, things whose cryptographic hash is in the .nix source code, and nothing else. There is an --impure flag which lets it read from (but not write to) the filesystem but nixpkgs does not use that.

That is a pretty big rift that I find myself unable to cross. I can eval Nix code from any random bozo on the interwebs without having to trust them. If I trust the nix sandbox (which I mostly do) I can even build the resulting drv. I can be sure that evaluating that Nix code will produce exactly the same drv two years from now that it did today. Guix doesn't offer those things. Because scheme. I'm sorry but scheme just isn't the right language for this, it's too powerful.

[tempaccount420]

There is Tvix, a Rust implementation of Nix, and although it still uses the Nix programming language, I bet it would be a lot easier to replace it there than in the original C++ codebase. (not just because of the language of implementation)

https://github.com/tvlfyi/tvix

To me, the perfect solution would be to have a base like Nix/Tvix you can build on top of, for example to make a package manager for your language, and have the users of that language's PM interact with TOML or JSON.

[dzogchen]

The main reason for the persistence of C despite its warts and general mess is just "first-mover advantage": it was the first, therefore it has more libraries/packages/development of the ecosystem than the alternatives.

Stop being lazy, go back to engineering first principles and it makes little sense to stay with C. [Insert systems programming language du jour] or any other well-developed language makes more sense.

[busterarm]

It's not just "first-mover advantage". I wouldn't even say it's mainly first-mover advantage.

It's the need to maintain super legacy systems and interoperability. There are entire CPU architectures that LLVM does not support and are only commonly supported by C and these things are still everywhere and are really gnarly problems to replace them.

Even if you throw everything away on the software side and start over from scratch, that's going to _force_ you to replace some hardware somewhere that you won't or can't replace.

[tempaccount420]

I see nothing wrong with this statement. Spice it up by inserting Rust at the blank and I can fully agree.

[aredox]

... Yes.

[tripdout]

I think Nix is much simpler and more suited for software packaging than Scheme.

[orthecreedence]

I don't think any general purpose language ever invented is simpler than lisp/scheme. I've not taken the time to familiarize myself with Nix yet, and one of the reasons is that the syntax of learning yet another language with its own idioms and syntax isn't something I care to tackle right now. I would love to reap the benefits of something like Nix, but something like Guix is much more appealing to me.

[TwentyPosts]

The Nix language is laughably simple, though, and (unlike Scheme) it happens to be typed.

It's literally just typed JSON with functions and a few built-ins. It's laughably simple and great. The whole "yet another programming language" refrain is so silly when it comes to Nix.

[slekker]

A shame Guix does not work on Mac and probably never will

[hamandcheese]

I think the main reason actually is that nix supports more than just Linux - notably macOS.

[_cenw]

The quality of Nix packages for Darwin is quite bad compared to Linux though, I don't think there's a core maintainer that runs Nix on Darwin.

[hamandcheese]

By quality do you mean quantity? Sure some packages are missing on Darwin, but those that aren't don't seem "worse" in any way.

[_cenw]

Broken builds often take quite a while to be noticed, and there aren't many people to reproduce them. Recently, as an example, `ncdu` broke.

[karma_pharmer]

There is one: @reckenrode. He's really good. But yeah only one person who knows nixpkgs inside-out runs Darwin. Low bus factor.