4 ms·

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

by aredox 2y ago

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 2y ago
Cabal has had nix-style local builds since 2016: https://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/ https://blog.ezyang.com/2016/05/announcing-cabal-new-build-n... https://cabal.readthedocs.io/en/2.0/nix-local-build-overview.html 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.
- Macha 2y ago
  You'll also need to deal with project philosophy regarding closed source packages to get Guix as streamlined as Nix.
- karma_pharmer 2y ago
  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 2y ago
    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 https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/overrides/default.nix 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/overrides/build-systems.json https://github.com/nix-community/poetry2nix/blob/master/over...)
ahnix 2y ago
[dead]
dzogchen 2y ago
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.
- aredox 2y ago
  ... Yes.
- tempaccount420 2y ago
  I see nothing wrong with this statement. Spice it up by inserting Rust at the blank and I can fully agree.
- busterarm 2y ago
  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.
tripdout 2y ago
I think Nix is much simpler and more suited for software packaging than Scheme.
- orthecreedence 2y ago
  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.
  - slekker 2y ago
    A shame Guix does not work on Mac and probably never will
  - TwentyPosts 2y ago
    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.
hamandcheese 2y ago
I think the main reason actually is that nix supports more than just Linux - notably macOS.
- _cenw 2y ago
  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.
  - karma_pharmer 2y ago
    There is one: @reckenrode. He's really good. But yeah only one person who knows nixpkgs inside-out runs Darwin. Low bus factor.
  - hamandcheese 2y ago
    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 2y ago
      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.
tempaccount420 2y ago
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 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.
karma_pharmer 2y ago
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.

by aredox 2y ago

ParetoOptimal 2y ago

Cabal has had nix-style local builds since 2016: https://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/ https://blog.ezyang.com/2016/05/announcing-cabal-new-build-n... https://cabal.readthedocs.io/en/2.0/nix-local-build-overview.html 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.

Macha 2y ago
You'll also need to deal with project philosophy regarding closed source packages to get Guix as streamlined as Nix.
karma_pharmer 2y ago
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 2y ago
  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 https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/overrides/default.nix 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/overrides/build-systems.json https://github.com/nix-community/poetry2nix/blob/master/over...)

ahnix 2y ago

[dead]

dzogchen 2y ago

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.

aredox 2y ago
... Yes.
tempaccount420 2y ago
I see nothing wrong with this statement. Spice it up by inserting Rust at the blank and I can fully agree.
busterarm 2y ago
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.

tripdout 2y ago

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

orthecreedence 2y ago
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.
- slekker 2y ago
  A shame Guix does not work on Mac and probably never will
- TwentyPosts 2y ago
  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.

hamandcheese 2y ago

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

_cenw 2y ago
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.
- karma_pharmer 2y ago
  There is one: @reckenrode. He's really good. But yeah only one person who knows nixpkgs inside-out runs Darwin. Low bus factor.
- hamandcheese 2y ago
  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 2y ago
    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.

tempaccount420 2y ago

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

karma_pharmer 2y ago

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.