7 ms·

> Nix often scares newcomers and experienced devs alike, because it proposes a fairly radical overhaul to how we think about package management and how we run s

> Nix often scares newcomers and experienced devs alike, because it proposes a fairly radical overhaul to how we think about package management and how we run software in general. I am not sure this is the main put-off of nix. Ideologically, I love nix. The syntax/language itself is a massive barrier IMO. I use Nix for personal projects, but I prefer the experience of Devcontainers. They're easier to understand and debug (for me). I'm watching eagerly the work being done by the ostree/rpm-ostree folks who are also trying to solve for a similar problem. Hoping to see something like "Nix but with YAML/JSON" come out of that. https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix https://ostree.readthedocs.io/en/stable/manual/related-proje...

Ericson2314 5y ago
By their own text in what you linked: > OSTree only supports only system-level images, and doesn't do dependency management. I think that makes it....not really like Nix at all. Dependency management is Nix's core functionality. Everything I would happily delegate to other layers.
- octoberfranklin 5y ago
  ... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I've been seeing a lot of "steal their thunder" type project positioning lately when something is a radical leap forward but requires major effort to learn -- like nix or rust. People seem to have picked up on a strategy that if you can put together something inferior but easier to understand (zig doesn't need a borrow checker because it's memory-unsafe; ostree doesn't need a language because it ignores dependencies), and market it as an alternative to the radical thing, a much larger group of people will rally around the simpler thing instead of the radical thing because they feel threatened by the new thing that can't be learned in a weekend or even a week, and using only "20%-time" would take six months to master... I'm going to get downvoted to hades for this, but it's true.
  - ajb 5y ago
    I don't see ostree promote themselves as an alternative to Nix. The GP linked to an explainer of how OStree differs from a bunch of systems, not really a promotional page. And in general OStree's use case is different to Nix so I don't think it competes. You may be right that this is a pattern, but I don't see it in this case.
  - microtonal 5y ago
    ... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I think that this comparison is unfair. First of all, the OSTree documentation doesn't pretend that it is something like Nix. It's an object storage for operating system images. Secondly, in contrast go Zig, OSTree most likely wider use/deployments than Nix, since it is used by Fedora CoreOS and Fedora Silverblue. That said, even though Nix and OSTree are not very similar. For users, there are similar benefits: an immutable system, atomic upgrades/rollbacks, etc. I think it is also much more likely that OSTree gets into the hands of millions than Nix. (Disclaimer: I like Nix a lot and am a contributor to nixpkgs.)
  - sph 5y ago
    > I'm going to get downvoted to hades for this, but it's true. Yes, because it has nothing to do with Nix, but it's just your own off-topic crusade, and being concerned that when someone tries something different, they're "steal[ing] the thunder" from your own favourite pet project. Talk about feeling threatened. We can do better than having cults around our little language or package manager but instead learning to appreciate the little differences between each project. Perhaps the solution is in the intersection between the two.
MichaelBurge 5y ago
The language is small enough that there's no way it's a problem. It seems less complicated than YAML, a couple hours to pick up at most. I have a NixOS setup on my desktop and use Nix for some projects, but only maybe a week or two of experience. And the language was never an issue. The bigger problem is the standard library is a sprawling mess: Understanding what options are available or how to get your thing to build by analogy with someone else's, requires digging into nixpkgs with no good tool support. If you did a line-by-line port from Nix to YAML or Python but kept the standard library exactly the same, it would be even harder to understand.
- takeda 5y ago
  Yes, nixpkgs desperately needs to be split, at least into two packages: - stdlib - packages The stdlib could also include builders and language frameworks, or they could be split even further. Then treat the stdlib the same way as it is treated in any other language (make it stable, not changed frequently and make sure everything is documented with the release). That would reduce the need of reading source code to use nix.
  - Ericson2314 5y ago
    I am not so sure about that. Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ I wrote to hopefully make the lang2nix packages work with Nixpkgs. I think this would achieve most of the benefits of what you propose: cleaner separation of infra vs vs ad-hoc per-package stuff, while still retaining the flexibility of the monorepo. The goal is to work with upstream developers so less and less ad-hoc crap is needed. Then the one repo ends up "all stdlib no packages", because the packages are basically autogenerated!
    - takeda 5y ago
      I have mixed opinion about this. I mean, I understand that there are increasingly applications that are getting harder and harder to package, but if there are tools that could just parse lock files and build a project without any work, in that case why even package it, one could just have function where we could point to SCM repo and it would fetch and install the application. I'm still not fully understanding what import from derivation really mean (technically) is it an ability to fetch the source from repos during evaluation? If so, that is an issue. If one tries to use Nix in environment with repos that require authentication it is a huge pain. There was a workaround once with passing SSH configuration, but it was removed. I also think your RFC is orthogonal to what I suggested. I think #1 issue with Nix is steep learning curve, and huge part of it is documentation that is not up to date. The thing is, as others said, Nix is great when everything works, as soon as you step into something that's not as common suddenly things become really complex, because documentation is not enough, one has to dive into nixpkgs which is very complex. > Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. That's actually the problem I'm talking about. Because this infrastructure code is constantly changing => that makes the documentation be not up to date => makes Nix more difficult for others to start using it. You don't have difficulty with it because you know it inside and out, I know enough to usually find what I'm looking for, but from my own experience I remember it was really hard to get to the point where I'm and I'm still not that great at it. Normally if that was happening in any other language it would be considered to be not ready yet for wide use, but Nix does want to be used and think this is one of things needed. Even with up to date documentation it there are still difficult things, but at least it would be huge improvement. Imagine if Go or Python sdk was not up to date and the way to learn it would be studying sdk's source code. It would be a drastically different programming experience and I doubt people would call those languages beginner friendly.
n42 5y ago
I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. if you think you can approximate what Nix is capable of with YAML and be less complicated, I think you’ve missed the point. what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I don’t think most sys admins are fluent in functional programming, so it’s a huge turn off and learning curve. if you approach it as three problems: learn the basics of functional programming, learn the syntax of the Nix language, and only then learn what a derivation is and how it works, it will be a lot easier to approach. at that point the nixpkgs library starts to make a LOT more sense. I understand that’s a lot to ask when you just want to install some packages, though. It’s a tricky problem.
- temptemptemp111 5y ago
- dwohnitmok 5y ago
  > what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. I think I agree with this. > the difficulty people have with it is that it’s functional, not that it’s nix. No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong. The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong. There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.
salamandersauce 5y ago
I recently briefly tried Nix and yeah the language seems a bit tough with not too many resources floating around. I really don't want to learn a whole language just for my package manager. But then I discovered Guix which is inspired by Nix but uses Scheme instead of a custom thing. Seems more sensible and easier to understand as I know a little bit of lisp already.
cturtle 5y ago
Maybe Nix but with Lua?
- zamalek 5y ago
  You need a strictly pure functional language to do what Nix does. It's able to determine if something is already installed (in a specific state) because it calculates a hash of the output. Side effects throw a wrench in all of that.
  - tadfisher 5y ago
    Moreover, you need a _lazy_ functional language, because otherwise you are building every package in nixpkgs when evaluating it.
    - rixed 5y ago
      Wouldn't that be possible to build packages definitions instead? Isn't that what Guix is doing?
  - cturtle 5y ago
    Thanks! I guess I need to learn more about Nix then :)
  - naasking 5y ago
    The language doesn't need to be lazy. Strict languages model laziness via explicit lazy values. For Nix, this would be some kind of explicit package type. Side effects are problematic though.
  - SAI_Peregrinus 5y ago
    I feel like a logic programming language (e.g. Prolog) would be a better fit for what Nix is trying to do than a functional one like Nix. Of course those are even less familiar to most devs than functional languages, so it wouldn't solve the "weird new language" issue.
zamalek 5y ago
Guix was a unmitigated disaster for me: after at least an hour of tinkering I got the installer ISO to boot. Not long after linux-libre managed to install itself again, and my machine stopped booting. Not practical, at all. > The syntax/language itself is a massive barrier IMO. But oh boy was this a joy. The Nix language isn't that bad (Dhall has the potential to surpass it), but Guix gave me seriously rich error messages, and lisp works great with almost any editor. Overlays and home-manager just grew out of nix and either lack ergonomics or decedent error messages (compared to Guix). Flakes improve the situation, but nix still feels "all over the place." I run Nix on my desktop, but I'm actively working on a Dhall-based replacement.
- infogulch 5y ago
  What do you think of dhall-nix? (I mentioned elsewhere itt.)
  - zamalek 5y ago
    It's still Nix. To be clear: I have extremely high praise for nix, and I'm getting nix-darwin going at work for engineer onboarding. That being said, it feels more like a research project. It pioneers some extremely important ideas and, by necessity, some of those ideas are "bolt-ons" and truly just feel like a proof of concept. Guix, for example, has home-manager built right in and doesn't suffer from the error message issues that home-manager does. I used Arch, btw, and AUR was truly a thing of beauty. PPAs (of Ubuntu) are, in theory, even better. Have you seen the sheer amount of effort it takes to keep nixpkgs going?[1] Home-manager, amazing thing that it is, has several issues. From their own documentation: > Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem. Flakes? Experimental: > Nix Flakes are an upcoming feature of the Nix package manager. I also think it should be possible for the mainline (e.g. nixpkgs) to import a flake: the nixpkgs maintenance nightmare has to end. Dhall can do that, and will even verify it with a hash[2]. They came up with extremely important ideas, but the same ideas taken as a whole (instead of iteratively) could be combined into something far greater. [1]: https://github.com/NixOS/nixpkgs/commits/master https://github.com/NixOS/nixpkgs/commits/master [2]: https://github.com/dhall-lang/dhall-lang/blob/master/standard/imports.md https://github.com/dhall-lang/dhall-lang/blob/master/standar...
ParetoOptimal 5y ago
> Ideologically, I love nix. The syntax/language itself is a massive barrier IMO. Really rooting for the Nickel project which is a new configuration language aims to allow for gradual typing and contracts for Nix expressions: https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing/ https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing/
- zeec123 5y ago
  Or PureNix: https://functor.tokyo/blog/2022-01-03-purenix https://functor.tokyo/blog/2022-01-03-purenix
zeec123 5y ago
Maybe PureNix helps lowering this barrier.
zeec123 5y ago
Have a look at PureNix: https://functor.tokyo/blog/2022-01-03-purenix https://functor.tokyo/blog/2022-01-03-purenix

Ericson2314 5y ago

By their own text in what you linked: > OSTree only supports only system-level images, and doesn't do dependency management. I think that makes it....not really like Nix at all. Dependency management is Nix's core functionality. Everything I would happily delegate to other layers.

octoberfranklin 5y ago
... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I've been seeing a lot of "steal their thunder" type project positioning lately when something is a radical leap forward but requires major effort to learn -- like nix or rust. People seem to have picked up on a strategy that if you can put together something inferior but easier to understand (zig doesn't need a borrow checker because it's memory-unsafe; ostree doesn't need a language because it ignores dependencies), and market it as an alternative to the radical thing, a much larger group of people will rally around the simpler thing instead of the radical thing because they feel threatened by the new thing that can't be learned in a weekend or even a week, and using only "20%-time" would take six months to master... I'm going to get downvoted to hades for this, but it's true.
- ajb 5y ago
  I don't see ostree promote themselves as an alternative to Nix. The GP linked to an explainer of how OStree differs from a bunch of systems, not really a promotional page. And in general OStree's use case is different to Nix so I don't think it competes. You may be right that this is a pattern, but I don't see it in this case.
- microtonal 5y ago
  ... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I think that this comparison is unfair. First of all, the OSTree documentation doesn't pretend that it is something like Nix. It's an object storage for operating system images. Secondly, in contrast go Zig, OSTree most likely wider use/deployments than Nix, since it is used by Fedora CoreOS and Fedora Silverblue. That said, even though Nix and OSTree are not very similar. For users, there are similar benefits: an immutable system, atomic upgrades/rollbacks, etc. I think it is also much more likely that OSTree gets into the hands of millions than Nix. (Disclaimer: I like Nix a lot and am a contributor to nixpkgs.)
- sph 5y ago
  > I'm going to get downvoted to hades for this, but it's true. Yes, because it has nothing to do with Nix, but it's just your own off-topic crusade, and being concerned that when someone tries something different, they're "steal[ing] the thunder" from your own favourite pet project. Talk about feeling threatened. We can do better than having cults around our little language or package manager but instead learning to appreciate the little differences between each project. Perhaps the solution is in the intersection between the two.

MichaelBurge 5y ago

The language is small enough that there's no way it's a problem. It seems less complicated than YAML, a couple hours to pick up at most. I have a NixOS setup on my desktop and use Nix for some projects, but only maybe a week or two of experience. And the language was never an issue. The bigger problem is the standard library is a sprawling mess: Understanding what options are available or how to get your thing to build by analogy with someone else's, requires digging into nixpkgs with no good tool support. If you did a line-by-line port from Nix to YAML or Python but kept the standard library exactly the same, it would be even harder to understand.

takeda 5y ago
Yes, nixpkgs desperately needs to be split, at least into two packages: - stdlib - packages The stdlib could also include builders and language frameworks, or they could be split even further. Then treat the stdlib the same way as it is treated in any other language (make it stable, not changed frequently and make sure everything is documented with the release). That would reduce the need of reading source code to use nix.
- Ericson2314 5y ago
  I am not so sure about that. Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ I wrote to hopefully make the lang2nix packages work with Nixpkgs. I think this would achieve most of the benefits of what you propose: cleaner separation of infra vs vs ad-hoc per-package stuff, while still retaining the flexibility of the monorepo. The goal is to work with upstream developers so less and less ad-hoc crap is needed. Then the one repo ends up "all stdlib no packages", because the packages are basically autogenerated!
  - takeda 5y ago
    I have mixed opinion about this. I mean, I understand that there are increasingly applications that are getting harder and harder to package, but if there are tools that could just parse lock files and build a project without any work, in that case why even package it, one could just have function where we could point to SCM repo and it would fetch and install the application. I'm still not fully understanding what import from derivation really mean (technically) is it an ability to fetch the source from repos during evaluation? If so, that is an issue. If one tries to use Nix in environment with repos that require authentication it is a huge pain. There was a workaround once with passing SSH configuration, but it was removed. I also think your RFC is orthogonal to what I suggested. I think #1 issue with Nix is steep learning curve, and huge part of it is documentation that is not up to date. The thing is, as others said, Nix is great when everything works, as soon as you step into something that's not as common suddenly things become really complex, because documentation is not enough, one has to dive into nixpkgs which is very complex. > Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. That's actually the problem I'm talking about. Because this infrastructure code is constantly changing => that makes the documentation be not up to date => makes Nix more difficult for others to start using it. You don't have difficulty with it because you know it inside and out, I know enough to usually find what I'm looking for, but from my own experience I remember it was really hard to get to the point where I'm and I'm still not that great at it. Normally if that was happening in any other language it would be considered to be not ready yet for wide use, but Nix does want to be used and think this is one of things needed. Even with up to date documentation it there are still difficult things, but at least it would be huge improvement. Imagine if Go or Python sdk was not up to date and the way to learn it would be studying sdk's source code. It would be a drastically different programming experience and I doubt people would call those languages beginner friendly.

n42 5y ago

I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. if you think you can approximate what Nix is capable of with YAML and be less complicated, I think you’ve missed the point. what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I don’t think most sys admins are fluent in functional programming, so it’s a huge turn off and learning curve. if you approach it as three problems: learn the basics of functional programming, learn the syntax of the Nix language, and only then learn what a derivation is and how it works, it will be a lot easier to approach. at that point the nixpkgs library starts to make a LOT more sense. I understand that’s a lot to ask when you just want to install some packages, though. It’s a tricky problem.

temptemptemp111 5y ago
dwohnitmok 5y ago
> what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. I think I agree with this. > the difficulty people have with it is that it’s functional, not that it’s nix. No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong. The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong. There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.

salamandersauce 5y ago

I recently briefly tried Nix and yeah the language seems a bit tough with not too many resources floating around. I really don't want to learn a whole language just for my package manager. But then I discovered Guix which is inspired by Nix but uses Scheme instead of a custom thing. Seems more sensible and easier to understand as I know a little bit of lisp already.

cturtle 5y ago

Maybe Nix but with Lua?

zamalek 5y ago
You need a strictly pure functional language to do what Nix does. It's able to determine if something is already installed (in a specific state) because it calculates a hash of the output. Side effects throw a wrench in all of that.
- tadfisher 5y ago
  Moreover, you need a _lazy_ functional language, because otherwise you are building every package in nixpkgs when evaluating it.
  - rixed 5y ago
    Wouldn't that be possible to build packages definitions instead? Isn't that what Guix is doing?
- cturtle 5y ago
  Thanks! I guess I need to learn more about Nix then :)
- naasking 5y ago
  The language doesn't need to be lazy. Strict languages model laziness via explicit lazy values. For Nix, this would be some kind of explicit package type. Side effects are problematic though.
- SAI_Peregrinus 5y ago
  I feel like a logic programming language (e.g. Prolog) would be a better fit for what Nix is trying to do than a functional one like Nix. Of course those are even less familiar to most devs than functional languages, so it wouldn't solve the "weird new language" issue.

zamalek 5y ago

Guix was a unmitigated disaster for me: after at least an hour of tinkering I got the installer ISO to boot. Not long after linux-libre managed to install itself again, and my machine stopped booting. Not practical, at all. > The syntax/language itself is a massive barrier IMO. But oh boy was this a joy. The Nix language isn't that bad (Dhall has the potential to surpass it), but Guix gave me seriously rich error messages, and lisp works great with almost any editor. Overlays and home-manager just grew out of nix and either lack ergonomics or decedent error messages (compared to Guix). Flakes improve the situation, but nix still feels "all over the place." I run Nix on my desktop, but I'm actively working on a Dhall-based replacement.

infogulch 5y ago
What do you think of dhall-nix? (I mentioned elsewhere itt.)
- zamalek 5y ago
  It's still Nix. To be clear: I have extremely high praise for nix, and I'm getting nix-darwin going at work for engineer onboarding. That being said, it feels more like a research project. It pioneers some extremely important ideas and, by necessity, some of those ideas are "bolt-ons" and truly just feel like a proof of concept. Guix, for example, has home-manager built right in and doesn't suffer from the error message issues that home-manager does. I used Arch, btw, and AUR was truly a thing of beauty. PPAs (of Ubuntu) are, in theory, even better. Have you seen the sheer amount of effort it takes to keep nixpkgs going?[1] Home-manager, amazing thing that it is, has several issues. From their own documentation: > Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem. Flakes? Experimental: > Nix Flakes are an upcoming feature of the Nix package manager. I also think it should be possible for the mainline (e.g. nixpkgs) to import a flake: the nixpkgs maintenance nightmare has to end. Dhall can do that, and will even verify it with a hash[2]. They came up with extremely important ideas, but the same ideas taken as a whole (instead of iteratively) could be combined into something far greater. [1]: https://github.com/NixOS/nixpkgs/commits/master https://github.com/NixOS/nixpkgs/commits/master [2]: https://github.com/dhall-lang/dhall-lang/blob/master/standard/imports.md https://github.com/dhall-lang/dhall-lang/blob/master/standar...

ParetoOptimal 5y ago

> Ideologically, I love nix. The syntax/language itself is a massive barrier IMO. Really rooting for the Nickel project which is a new configuration language aims to allow for gradual typing and contracts for Nix expressions: https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing/ https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing/

zeec123 5y ago
Or PureNix: https://functor.tokyo/blog/2022-01-03-purenix https://functor.tokyo/blog/2022-01-03-purenix

zeec123 5y ago

Maybe PureNix helps lowering this barrier.

zeec123 5y ago

Have a look at PureNix: https://functor.tokyo/blog/2022-01-03-purenix https://functor.tokyo/blog/2022-01-03-purenix