Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will Nix Overtake Docker?

blog.replit.com

Post reply on HN
Print view View original

251–259 of 259 posts

Re: Will Nix Overtake Docker?

#251

Post by jessaustin »

stevebmark wrote: post #104
kortex wrote: post #91

As TFA itself answers, "no". But I can give a different reason: nix is too much of a barrier of entry, relative to Docker. Docker might not be simple ; there's a lot of moving parts to manage, some hidden gotchas, and networks are a mess. But it's comparatively easy , and once you bake an image, it's pretty simple . Dockerfiles are basically just sh. Package managers are the usual suspects. Images are easy to distrib…

I agree, there’s a reason no one uses Nix. It has terrible DX

Does it seem weird to anyone that Nix insists on installing its "/nix" directory on the root directory rather than somewhere sensible like "/usr" or even "/usr/local" ?

Re: Will Nix Overtake Docker?

#252

Post by xelxebar »

MereInterest wrote: post #170
xelxebar wrote: post #138

Earlier quoted context omitted.

Heh. Though while we're playing Pedantics, it's worth pointing out that the defining characteristic of Heat Death is maximum entropy, not uniform temperature. That said, it's entirely possible that the whole system of Energy Company + OP's computer actually does get cooler on average when compiling Haskell. Here's a fun game. Have you ever played Follow the Energy? For example, depressing keys on your keyboard takes…

> The sun! That? Nuclear fusion. That? Gravitational potential! That? Etc... Minor pedantry on top of pedantry. The gravitational potential energy of a collapsing protostar gets you past the activation barrier for nuclear fusion, but isn't itself the source of energy beyond that. Think of it like lighting campfire using friction. The friction heats up the kindling, but that investment allows you to access the potenti…

Thanks! That's one place in the chain that I paused for quite a while, deliberating what to write down. Overall, the little "causal chain" I wrote down is littered with little (but useful!) fibs, and the one you point out is probably the most egregious.

Nice analogy, btw.

Re: Will Nix Overtake Docker?

#253

Post by nirui »

chriswarbo wrote: post #148
nirui wrote: post #81

Earlier quoted context omitted.

Agreed with your opinion about `Dockerfile`. The article had me for a second until I saw the script code. I mean, my time is not infinite and I rather spend it to do things that are really important to me, not learning to write "yet-another build script" for a small system. So unless it's mainstream already, I'm not going to touch it. `Dockerfile` is light enough for me to not hate it too much. For the `docker-compos…

> I mean, my time is not infinite and I rather spend it to do things that are really important to me, not learning to write "yet-another build script" for a small system. You don't have to jump into the deep end with Nix. If you're happy to just run shell commands (like Dockerfiles provide), then all you need is this: (import {}).runCommand "my-package" {} '' PUT YOUR BASH CODE HERE ''

No, please don't interpret it like this.

No matter what the format Nix script look like, it's still a script language designed to address something that has already been addressed (or can be addressed with light expansions). The very idea of "Hey let's build this whole new thing that does this specific old task a little bit better at the cost of learning many new concepts (and making many mistakes)" is not good at the core.

I would rather say, if the dudes there really wants to create a new language, fine, but at least make it big. By that, I mean don't just try to build a tool that preforms the old task a little bit better (at cost of learning), make a tool that does new things (in other words, "enables new possibilities") far better. Perhaps after that, the toolset could become something worth learning for.

(Currently, there are many ways to create reproducible builds. And even if you have reproducible builds, it does not mean the build will reproduce the same runtime result all the time. All factors combine, the benefit you can receive from the toolset is just not great enough at the moment. Hope you understand my point)

Re: Will Nix Overtake Docker?

#254

Post by roguas »

amarshall wrote: post #103
exdsq wrote: post #50

Earlier quoted context omitted.

Thanks, this is the one! Highly recommend it, especially when you're in the HN echo chamber of new and interesting technologies

Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.

Nix popularity is still lower than Docker, even during dotcloud era(I think this was the og company). Boring means common, unnuanced, rather than older or first.

Re: Will Nix Overtake Docker?

#255

Post by jonstewart »

clhodapp wrote: post #41
jonstewart wrote: post #13

Earlier quoted context omitted.

You can use Nix to create a tarball that can then be launched as a Docker container. However, I haven’t figured out a way to make Nix play nicely with container image layering—you get a small container image for deployment, but you’ll have lots of such largely-duplicative tarballs in the CI pipeline and the latency for generating them is annoying.

Have you tried dockerTools.buildLayeredImage ( https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo... )? It applies some smart heuristics ( https://grahamc.com/blog/nix-and-layered-docker-images ) to create images made of pretty reusable layers. This is subject to some false cache misses due to some laziness in the docker's cache implementation ( https://github.com/moby/moby/issues/38446 ), but that is Docke…

No, hadn’t seen that. Thanks!

Re: Will Nix Overtake Docker?

#256

Post by svenhy »

kaba0 wrote: post #112
salamander014 wrote: post #9

I think people are missing the forest for the trees with this. In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds. It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge. Yes, Nix is 'better', but the fact…

That’s because Docker just pushes dependency management to one layer below, doesn’t solve it.

Well I think both Nix and Docker delegate the actual resolution of dependencies and it's not about implicit vs explicit dependency management, alone, it's more that with explicit dependency management you get reproducability.

And with reproducability you move the work from fixing broken builds, to implementing builds.

Of course, I can tag docker images and upload them to an internal registry, but that seems more complex to me, than doing this at the source level with Nix.

Re: Will Nix Overtake Docker?

#257

Post by chriswarbo »

nirui wrote: post #253
chriswarbo wrote: post #148

Earlier quoted context omitted.

> I mean, my time is not infinite and I rather spend it to do things that are really important to me, not learning to write "yet-another build script" for a small system. You don't have to jump into the deep end with Nix. If you're happy to just run shell commands (like Dockerfiles provide), then all you need is this: (import {}).runCommand "my-package" {} '' PUT YOUR BASH CODE HERE ''

No, please don't interpret it like this. No matter what the format Nix script look like, it's still a script language designed to address something that has already been addressed (or can be addressed with light expansions). The very idea of "Hey let's build this whole new thing that does this specific old task a little bit better at the cost of learning many new concepts (and making many mistakes)" is not good at th…

> The very idea of "Hey let's build this whole new thing that does this specific old task a little bit better at the cost of learning many new concepts (and making many mistakes)" is not good at the core.

You don't seem to have a problem with Dockerfiles, yet Nix was around for a decade before Docker existed. If you don't want people to reinvent things that already work, then your complaint should be directed at Dockerfiles. In fact, you should go and complain at the following projects, which were (a) created after Nix, (b) try to solve some subset of things that Nix can already handle and (c) are strictly worse than Nix (e.g. less secure, not reproducible, not cross-platform, tied to one language, etc.):

- Docker

- NPM

- Puppet

- Ansible

- Salt

- Webpack

- Grunt

- Gulp

- Homebrew

- Pip

- Conda

- Poetry

- Gradle

- Vagrant

- etc.

Re: Will Nix Overtake Docker?

#258

Post by mst »

dnautics wrote: post #249
mst wrote: post #160

Earlier quoted context omitted.

Possibly https://buildah.io/ would be of interest.

I do use podman, not really stoked about buildah because it's still a bunch of buildah commands in a shell-driven DSL, which I suppose is better than a dockerfile. Singularity was literally a build file that was a shell script divided into sections that denoted phases.

Bit late now but you could probably make something like it using buildkit - https://github.com/moby/buildkit/blob/master/examples/buildk...

Re: Will Nix Overtake Docker?

#259

Post by doublepg23 »

rekado wrote: post #145
doublepg23 wrote: post #69

Earlier quoted context omitted.

Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...

This gets repeated a lot, but Guix really is not a fork of Nix. Not by any definition of "fork". Also not "a fork of sorts". The term "fork" only applies to one executable: "guix-daemon", which is a literal fork of "nix-daemon". They have, of course, diverged a lot, but this (and nothing else) is truly a fork. Aside from this one executable there is no relationship between the two projects. The daemon takes .drv file…

I love reading your blogs on Guix, I'll keep that in mind for future reference sorry for the libel ;)
Post reply on HN