4 ms·

There are two sides to this problem, the first is to improve the UX, but the second is to clearly describe a compelling reason for people to adopt. It is very t

There are two sides to this problem, the first is to improve the UX, but the second is to clearly describe a compelling reason for people to adopt. It is very tempting to only blame the first, but I think we need to also need to tell a better story and highlight the values in a better way. This would then give people a reason to get past the UX issues in the hopes of achieving those desired values. For example; people seem to have accepted that the benefits of using terraform in spite of various difficulties - the learning of its language or needing to hire specialists. The mantra of "infrastructure as code" is enough to drive adoption. What is our mantra? We need to accept that "reproducibility" isn't quite working and that we need either a clearer message, or to explain the message.

carapace 4y ago
I disagree, I think the value proposition for reproducibility is clear, it's just that the learning curve "is too damn high!" I'm highly motivated to learn and use Nix (or Guix for that matter) but I've bounced off of it three or four times now, and I'm the kind of weirdo who learns new PLs for fun. Someone once said that you don't learn Nix, you reverse engineer it.
- takeda 4y ago
  I think the reason why Nix is hard isn't the language (although lazily evaluated functional language is definitively a part of it), but the paradigm shift, but this is necessary for reproducibility. Imagine if you had a distro where you couldn't depend on existing state (so you couldn't just compile something to /usr/local). Where you had to create package definition with all dependencies explicitly defined. Kind of like using FreeBSD ports (or Gentoo) without precompiled packages and you were forced to add every package manually before using. You would also complain it is hard even if you would have to just use Makefile and shell script. I don't think this will get easier until Nix would get embraced by other package s, making it easy to specify those components as dependencies. Now with flakes with can be composable this is possible.
- IshKebab 4y ago
  I agree with you. I can see the value of reproducibility, declarative system setup, etc. I would love that. But there's no way I'm fighting software with such a bad UX.
rgoulter 4y ago
> We need to accept that "reproducibility" isn't quite working... I guess it doesn't sell Nix as strongly as it could.. But, it's hardly for a lack of enthusiasm on Nix user's part. -- Rather, I've seen a few "what's nix good for anyway" comments, and this results in many lengthy replies extolling nix.
soraminazuki 4y ago
Agreed, reproducibility is only one aspect of Nix and doesn't quite capture the whole picture. That's why so many newcomers see Nix as nothing more than a Docker replacement. There's also too much misconceptions about Nix the language that's scaring people off. I'd like to see more being discussed about: * Its unique ability to treat packages as programmable data (i.e., derivations) * Its use case as a building block for deployment systems that knows about and integrates with packages * Its JSON-like simplicity They're all central to the Nix experience, and yet it's often overlooked in Nix discussions.
- Zurrrrr 4y ago
  > Its unique ability to treat packages as programmable data (i.e., derivations) How is this useful in practice?
  - VTimofeenko 4y ago
    It's super easy to extend packages. For example, I was playing with Kafka and wanted the standard package to coexist with a separate install of Kafka with some jar files I needed. It was super easy to create a new package of Kafka with extra install steps that downloaded and placed those jar files where I needed.
  - orbisvicis 4y ago
    I'm surprised that nix never ended up using augeas for package configuration because last I checked every upstream build option has to be reproduced in nix script by the packager.
    - soraminazuki 4y ago
      It's easy enough for users to extend existing packages in Nix that it's never necessary for packagers to explicitly add support for every conceivable upstream build option out there. For example, the following three lines will create a new package based on an existing one with custom configure flags added. existingPackage.overrideAttrs (old: { configureFlags = old.configureFlags ++ [ "--custom-build-option" ]; }) Package options that tweak the build flags are there for convenience and not a requirement. Many of them are there for internal use in the Nixpkgs repo to provide variants of the same package.
troutwine 4y ago
Two of the major differences between terraform and Nix that I see are 1. it’s possible to muddle through in terraform and 2. Hashicorp has put a non-trivial amount of effort into documentation for all levels of users. I’ve taken a stab at using Nix for Rust projects and could not even get to a point where I had something that functioned. I found plenty of material online but was it out of date, idiosyncratic, did it use flakes or not, etc etc? I suppose I could have contorted my existing project to meet the examples I found in various GitHub repos but my stuff is bog standard Rust so I don’t know that I’d be willing to. As for documentation, what should I, as a new and invested user, be looking for? Are flakes the future? Are they a distraction? Why are all the suggested docs I could find several year old guides on blogs? There’s 20 years of information floating around and the official project documentation, well, I don’t know who the audience is but it’s not learners. It’s a shame. The promise of Nix/NixOS is really interesting — being able to deterministically create VMs with a custom user land is desirable to me — but in practice I can’t even get a simplistic project to compile, let alone something elaborate. Terraform is jank but it’s not a whole language that needs to be learned, seemingly, before the official docs start to become coherent in their underlying context.
- earthling8118 4y ago
  I don't think it's very valid to compare the two. It is a little bit just to compare the experiences using them bit they aren't meant to solve the same set of issues. In fact, they are better together in my experience. I use nix to manage my terraform configurations with a lot of success. It reduces my boilerplate and helps me build abstractions on top of HCL. If you ever decide to take a stab at nix again, consider looking at https://github.com/ipetkov/crane https://github.com/ipetkov/crane and using flakes. I've got it down to the point that I can get a new rust project set up with nix in about 30 seconds with linting, package building, and test running all in the checks
  - troutwine 4y ago
    Crane is one of the libraries(?) I came across. Couldn’t get it to work on an existing multi-crate workspace project. The crane documentation as-is didn’t provide enough context to debug the errors I saw in the process of trying to muddle through. And then looking further afield ran into all the documentation, bootstrapping issues I alluded to above. Although I don’t doubt I could start a new project the point was to add new capability to existing work, for me.
grumbel 4y ago
> but the second is to clearly describe a compelling reason for people to adopt. Build source straight from Git: nix run github:someuser/someproject Need a different version? nix run github:someuser/someproject?ref=v1.0.0 Wanna replace some dependency? nix run \ --override-input somelib github:someotheruser/somelib \ github:someuser/someproject Wanna fork: git clone https://github.com/someuser/someproject # do your changes nix run someproject/ And the best part is, it's conceptually very simple, it's mostly just a bunch of symlinks and environment variables behind the scenes. If you wanna inspect what's in a package, just `cd /nix/store/yourpackage-HASH` and look around. NixOS just feels like a distribution build from the ground up for Free Software. The "reproducibility" in every day use just means that stuff won't randomly break for no reason. And if you don't wanna go the full NixOS route, you can just install the Nix package manager itself on any other distribution. That said, the part where Nix gets painful is when it has to interact with the rest of the software world. Things like software that wants to auto-update itself really does not fit into the Nix ecosystem at all and can be rather annoying to get to work. There are of course numerous other pain points, missing features and all that. But being able to flip between versions, fork, compile and all that with feels just so much better than anything else.
comfypotato 4y ago
I wonder if the corporate backing behind Docker has anything to do with Nix being adopted less. There’s a lot of overlap between Nix and Docker, and Docker had major corporate guns behind it from early on. Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem. Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier. It’s like comparing trucks (Docker) with planes (Nix) for logistics. I can pay out the wazoo for a plane to get my package there over night, or I can pay a small fraction to wait a few days.
- chriswarbo 4y ago
  > Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem. Docker isn't reproducible; I have no idea where this myth came from. The core feature of Docker is the ability to snapshot ("image") the result of a script ("Dockerfile"). That's no more "reproducible" than a statically-linked binary. > Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier. Personally, I find Docker incredibly difficult. I finally bit the bullet when I took over maintenance of some systems at work, which had been written with Docker. The documentation was awful, the management systems keep falling over, and we have no idea what's actually running (it's tagged ":latest", but so is everything). I avoid using anything Docker-related when I'm building new systems. It's easier to build container images with jq, tar and sha256sum anyway.
  - comfypotato 4y ago
    Docker serves the basic functionality of a container as well as any other. The workflows that forced you to migrate away from it are more complicated, I’m sure, than a procedurally defined dev environment. What you’re calling a snapshot is what I meant when I said reproducible. Images allow me to have reproducible starting points to add other parts to my environment. Over time they get out of date depending on exactly what happens, but it’s much more controllable than a basic Ubuntu installation. Your comment further pushes me away from Nix, really, even without mentioning it. It makes it seem even more like a tool that’s not for me, but rather for much more complicated things.

carapace 4y ago

I disagree, I think the value proposition for reproducibility is clear, it's just that the learning curve "is too damn high!" I'm highly motivated to learn and use Nix (or Guix for that matter) but I've bounced off of it three or four times now, and I'm the kind of weirdo who learns new PLs for fun. Someone once said that you don't learn Nix, you reverse engineer it.

takeda 4y ago
I think the reason why Nix is hard isn't the language (although lazily evaluated functional language is definitively a part of it), but the paradigm shift, but this is necessary for reproducibility. Imagine if you had a distro where you couldn't depend on existing state (so you couldn't just compile something to /usr/local). Where you had to create package definition with all dependencies explicitly defined. Kind of like using FreeBSD ports (or Gentoo) without precompiled packages and you were forced to add every package manually before using. You would also complain it is hard even if you would have to just use Makefile and shell script. I don't think this will get easier until Nix would get embraced by other package s, making it easy to specify those components as dependencies. Now with flakes with can be composable this is possible.
IshKebab 4y ago
I agree with you. I can see the value of reproducibility, declarative system setup, etc. I would love that. But there's no way I'm fighting software with such a bad UX.

rgoulter 4y ago

> We need to accept that "reproducibility" isn't quite working... I guess it doesn't sell Nix as strongly as it could.. But, it's hardly for a lack of enthusiasm on Nix user's part. -- Rather, I've seen a few "what's nix good for anyway" comments, and this results in many lengthy replies extolling nix.

soraminazuki 4y ago

Agreed, reproducibility is only one aspect of Nix and doesn't quite capture the whole picture. That's why so many newcomers see Nix as nothing more than a Docker replacement. There's also too much misconceptions about Nix the language that's scaring people off. I'd like to see more being discussed about: * Its unique ability to treat packages as programmable data (i.e., derivations) * Its use case as a building block for deployment systems that knows about and integrates with packages * Its JSON-like simplicity They're all central to the Nix experience, and yet it's often overlooked in Nix discussions.

Zurrrrr 4y ago
> Its unique ability to treat packages as programmable data (i.e., derivations) How is this useful in practice?
- VTimofeenko 4y ago
  It's super easy to extend packages. For example, I was playing with Kafka and wanted the standard package to coexist with a separate install of Kafka with some jar files I needed. It was super easy to create a new package of Kafka with extra install steps that downloaded and placed those jar files where I needed.
- orbisvicis 4y ago
  I'm surprised that nix never ended up using augeas for package configuration because last I checked every upstream build option has to be reproduced in nix script by the packager.
  - soraminazuki 4y ago
    It's easy enough for users to extend existing packages in Nix that it's never necessary for packagers to explicitly add support for every conceivable upstream build option out there. For example, the following three lines will create a new package based on an existing one with custom configure flags added. existingPackage.overrideAttrs (old: { configureFlags = old.configureFlags ++ [ "--custom-build-option" ]; }) Package options that tweak the build flags are there for convenience and not a requirement. Many of them are there for internal use in the Nixpkgs repo to provide variants of the same package.

troutwine 4y ago

Two of the major differences between terraform and Nix that I see are 1. it’s possible to muddle through in terraform and 2. Hashicorp has put a non-trivial amount of effort into documentation for all levels of users. I’ve taken a stab at using Nix for Rust projects and could not even get to a point where I had something that functioned. I found plenty of material online but was it out of date, idiosyncratic, did it use flakes or not, etc etc? I suppose I could have contorted my existing project to meet the examples I found in various GitHub repos but my stuff is bog standard Rust so I don’t know that I’d be willing to. As for documentation, what should I, as a new and invested user, be looking for? Are flakes the future? Are they a distraction? Why are all the suggested docs I could find several year old guides on blogs? There’s 20 years of information floating around and the official project documentation, well, I don’t know who the audience is but it’s not learners. It’s a shame. The promise of Nix/NixOS is really interesting — being able to deterministically create VMs with a custom user land is desirable to me — but in practice I can’t even get a simplistic project to compile, let alone something elaborate. Terraform is jank but it’s not a whole language that needs to be learned, seemingly, before the official docs start to become coherent in their underlying context.

earthling8118 4y ago
I don't think it's very valid to compare the two. It is a little bit just to compare the experiences using them bit they aren't meant to solve the same set of issues. In fact, they are better together in my experience. I use nix to manage my terraform configurations with a lot of success. It reduces my boilerplate and helps me build abstractions on top of HCL. If you ever decide to take a stab at nix again, consider looking at https://github.com/ipetkov/crane https://github.com/ipetkov/crane and using flakes. I've got it down to the point that I can get a new rust project set up with nix in about 30 seconds with linting, package building, and test running all in the checks
- troutwine 4y ago
  Crane is one of the libraries(?) I came across. Couldn’t get it to work on an existing multi-crate workspace project. The crane documentation as-is didn’t provide enough context to debug the errors I saw in the process of trying to muddle through. And then looking further afield ran into all the documentation, bootstrapping issues I alluded to above. Although I don’t doubt I could start a new project the point was to add new capability to existing work, for me.

grumbel 4y ago

> but the second is to clearly describe a compelling reason for people to adopt. Build source straight from Git: nix run github:someuser/someproject Need a different version? nix run github:someuser/someproject?ref=v1.0.0 Wanna replace some dependency? nix run \ --override-input somelib github:someotheruser/somelib \ github:someuser/someproject Wanna fork: git clone https://github.com/someuser/someproject # do your changes nix run someproject/ And the best part is, it's conceptually very simple, it's mostly just a bunch of symlinks and environment variables behind the scenes. If you wanna inspect what's in a package, just `cd /nix/store/yourpackage-HASH` and look around. NixOS just feels like a distribution build from the ground up for Free Software. The "reproducibility" in every day use just means that stuff won't randomly break for no reason. And if you don't wanna go the full NixOS route, you can just install the Nix package manager itself on any other distribution. That said, the part where Nix gets painful is when it has to interact with the rest of the software world. Things like software that wants to auto-update itself really does not fit into the Nix ecosystem at all and can be rather annoying to get to work. There are of course numerous other pain points, missing features and all that. But being able to flip between versions, fork, compile and all that with feels just so much better than anything else.

comfypotato 4y ago

I wonder if the corporate backing behind Docker has anything to do with Nix being adopted less. There’s a lot of overlap between Nix and Docker, and Docker had major corporate guns behind it from early on. Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem. Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier. It’s like comparing trucks (Docker) with planes (Nix) for logistics. I can pay out the wazoo for a plane to get my package there over night, or I can pay a small fraction to wait a few days.

chriswarbo 4y ago
> Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem. Docker isn't reproducible; I have no idea where this myth came from. The core feature of Docker is the ability to snapshot ("image") the result of a script ("Dockerfile"). That's no more "reproducible" than a statically-linked binary. > Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier. Personally, I find Docker incredibly difficult. I finally bit the bullet when I took over maintenance of some systems at work, which had been written with Docker. The documentation was awful, the management systems keep falling over, and we have no idea what's actually running (it's tagged ":latest", but so is everything). I avoid using anything Docker-related when I'm building new systems. It's easier to build container images with jq, tar and sha256sum anyway.
- comfypotato 4y ago
  Docker serves the basic functionality of a container as well as any other. The workflows that forced you to migrate away from it are more complicated, I’m sure, than a procedurally defined dev environment. What you’re calling a snapshot is what I meant when I said reproducible. Images allow me to have reproducible starting points to add other parts to my environment. Over time they get out of date depending on exactly what happens, but it’s much more controllable than a basic Ubuntu installation. Your comment further pushes me away from Nix, really, even without mentioning it. It makes it seem even more like a tool that’s not for me, but rather for much more complicated things.