Hacker News Reader

Comment by amarant | Hacker News Reader

Personally I'd prefer going with NixOS to achieve the same result. that way you don't even need a docker installation. As a bonus you can actually install the Nix package manager on osx if you're not into Linux (and this way there is no need for virtualization if you're on a Mac)

More info: https://nixos.org/

View on HN

As an added bonus, Nix can still easily output a container image for docker use containing the same shell environment.

I love the proposition, but frankly it seems to take too much time to learn even the basics. It would be awesome for someone to build a Docker-like experience on top of Nix, though.

Such is the life of a professional.

If you want to reach the areas where you can really improve your productivity, you're gonna have to take weeks or even months to learn something from the bottom up. There is no way around it, and it's the same in many industries. There is no "30 minutes to get more productive than anyone else" in reality, only hard work, understanding and application of your knowledge in the real world.

I’ve been working with Nix for years and I still find it to be disappointing. I don’t like Docker and I really love the Nix concept, but the execution seems poor. As an example, I spent half of a Saturday unsuccessfully working with people on the Nix Discord to get VS Code configured with some Rust plugins on MacOS. Similarly, if you need to write your own package, it might be easy or it might be a bottomless rabbit hole tar pit in which you have to package the entire dependency tree including a bunch of obscure C libraries with no build docs. More often than not it seems to be the latter. Further still, nixpkgs is horribly documented and dynamically typed and poorly organized, so every time you’re looking at a definition for a certain package and want to know what “shape” its dependencies have, you have to grep around for another package that uses it, then try to work out what that package is passing in as the dependency; however, if the dependency object is returned from another function defined in some other file you’ll just have to rinse and repeat until you come across the original definition. This is well below the bar for “professional work”. Problems like these arise every single time I try to work with Nix, and it becomes an enormous time sink. Docker is pretty shit, but there’s a pretty clear upper bound to the time I’ll spend struggling with it. Not so with Nix.

Can you link the Nix Discord?

As far as I know, the only official chat channels is #nixos (and #nixos-* friends) on Freenode (https://nixos.wiki/wiki/Get_In_Touch). There is an unofficial Discord, but I'd advice you to join the IRC channels instead, fast help and the people contributing to Nix actually hangs around as well.

I've actually had terrible success getting help through the official channels: it's why I asked.

I agree actually, you describe the issues I've had with nix quite head on. I've not ran into such issues every single time i try it, but I have hit upon a good deal of issues of the kind you describe. Nix is by no means perfect, and if I was smarter I'd try to remake it with a stronger type system, but the basic premise is useful enough on it's own to warrant usage IMO

I’ve thought a lot about a type system for Nix. Typing the mix expression language would improve some things, but since so much of what people do with the Nix expression language is writing scripts that take in files and transform them into other files, you would really want a type system for the derivations which could describe the “shape” of the input and output files. I’m not aware of any such type system, but it would be a really interesting area of research. Would love to know if others have thought about this or not.

So you just shifted your dependency from Docker to Nix. It might be more fun and an intetesting learning experience but also it's more complicated (or at least it's not that widely used like Docker is)

> So you just shifted your dependency from Docker to Nix

OTOH you don't have to write all this boilerplate code that's suggested in the article and your Nix environment is truly reproducible, whereas rebuilding a Docker image might not reproduce it faithfully. (Try running `apt-get install` in a Ubuntu container without running `apt-get update` first.) On top of that, if you've ever had to use more than two languages (+ toolchains) inside a single project, maybe even on multiple architectures[0], you'll appreciate Nix taking care of the entire bootstrap procedure.

[0]: Lots of dependencies that are easy to install on x86 need to be installed/compiled by hand on arm64.

Yes, learning nix is definitely an investment, but it's more powerful than docker, allowing you to create your entire setup, including drivers, desktop environment, and any userspace apps you might need, all declarative, and contained in a config file (or several if you prefer)

> It might be more fun and an intetesting learning experience but also it's more complicated

I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close.

> at least it's not that widely used like Docker is

"Which has more users" would not enter the top ten reasons I'd choose between tools like this.

I'm a major user of both and I can definitely say that Dockers basics are easier to learn and teach than Nixs basics. Maybe it has to do with the simple nature of the Dockerfile with just lines of commands, compared to Nix where you first need to learn the Nix language, then the idioms, then the package manager and now you can understand the OS. There is a couple of layers before things start making sense. While a Dockerfile is almost like a line-by-line shellscript.

At least that's my experience. Although I do prefer Nix over Docker any day, I'd definitely say the learning curve is steeper with Nix, but it's so worth it long-term.

>"Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Size of the community, especially if its quality, means you just increased your surface area at getting help for issues you encounter. Which is a very non-trivial concern in a work environment.

> "Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Why not? A big community means that you don't have to solve problems on your own, because someone else has probably solved the same problem before you.

If anything, it should be the <<first>> factor when making these decisions.

It means the ecosystem for Docker is more robust than for a Nix, which is patently true (see my comment here: https://news.ycombinator.com/item?id=26689378). I want to like Nix (and indeed I use it for some things), but it’s wildly immature, and maturity is a fine reason to choose one tool over another.

Also “imagine thinking...” is just vapid snark. If you must snark, at least make it substantial.

> I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close.

Well for starter Nix has a wider syntax because it covers much more than Docker + docker-compose. Which it's perfectly fine because they are two different tools that intersects in few use cases.

Syntax to install a few packages:

environment.systemPackages = with pkgs; [ wget vim nano zsh file ];

Including trailing semicolon. Dockerfile on alpine:

RUN apk add vim nano zsh file

I mean, maybe I'm too used to the latter but I really struggle to find the former simpler.

It looks impressive but it isn't clear how much you have to pay for services from them. It isn't free and you aren't in control. Your snapshots and abilities to rollback etc are likely to be dependent on their storage servers.

They certainly should monetise, but not making it clear is what I object to. I've raised as an issue for clarification in their community wiki.

https://github.com/nix-community/wiki/issues/34

Mmmm, no. Nix is not a SaaS that builds your snapshots that you have to pay for (or that "they need to monotize", what's wrong with people?), it's a whole ecosystem ranging from a full OS (NixOS) down to a package manager (Nix Package Manager) and programming language (just "Nix).

Not sure what needs clarification here, it's pretty up-front about it's mission and features already.

> Your snapshots and abilities to rollback etc are likely to be dependent on their storage servers

Not sure where you get this from. Snapshots are stored locally unless you specify otherwise, and then you'll get to chose whatever storage servers you want to use. Absolutely no "hidden" costs with Nix as it's a MIT licensed project and I don't think they even offer any "value-added" services nor paid customer support.

Edit: reading the issue you just created (https://github.com/nix-community/wiki/issues/34), I'm even more confused. "Given the need to monetise" is coming from where? Nowhere do they say that they have to monotize but don't know how/where, so where do you get this from? Not everything is about money.

I'm really impressed with it and am ONLY seeking clarity. I'll be extremely happy if I can use it standalone. Copyright, licensing are all I'm looking at.

e.g. Something like AGPL is considered copyleft and not compatible with 'open source' ethos. Still 'free' but the additional non-compete cloud service clause is both a sensible move, but something I'd just like to understand.

Your statement of 'what's wrong with people' is what is getting me. Borderline defensive. I'm definitely not knocking the product, quite the reverse. Its so good I want to embrace it wholeheartedly.

I have no problem paying for things, contributing voluntarily to a great product.

Its good to see that various organisations are committed to funding the infrastructure costs etc. (which negates my comment about storage servers).

As to monetisation,kind of irrelevant but was referring to paid services at the bottom of https://nixos.wiki/wiki/Nix_Ecosystem

> e.g. Something like AGPL is considered copyleft and not compatible with 'open source' ethos. Still 'free'

I’ve had to read this several times and still don’t understand what you’re talking about. AGPL is a Free Software license. All Free Software licenses (to my knowledge) provide source access. AGPL is also OSI-approved, so it is also an open source license.

It’s unclear what point you’re trying to make?

Issue 34 is now closed. My thanks to the patience of people there who have clarified and improved the visibility of licensing.

As noted below, my initial wording was unhelpful and misplaced.

The infrastructure costs are covered by sponsors. The 'They should monetise' was a 'they' that I now understand are external organisations rather than nixos themselves.

Reply on news.ycombinator.com