[chubot]

I honestly wonder why there are such divergent opinions between say git and Nix? (I've never used Nix, but I use git all the time) Is Nix so much harder to use than git?

git also has a clear model (the Merkle tree of file and directory nodes) but a famously unfriendly UI (git checkout does 5 or more unrelated things)

Some people do not like git, but I get the feeling that most people just use it, and get on with their day.

Why the difference with Nix? Maybe because building packages is inherently slower. Whereas you can quickly get yourself intro trouble with git, but you can also quickly get out of trouble (rm -rf, git clone)

Maybe Nix is more stateful? Although the git index/staging area I find to be a fabulously odd piece of state, and honestly breaks all the rules when I think about CLIs

Also Nix does rely on a very big global repo, whereas git doesn't

It also seems that Nix's model is less clean, and perhaps doesn't match the problem domain as well ... there are disagreements on whether it is "reproducible", etc.

Or maybe it's just a harder problem

[pxc]

You may not use Nix, but some pretty cool Nix tools use your work. :)

Just today I was working on some integrations with a runtime dependency resolver for shell programs that uses OSH for parsing on the job. We use Nix to manage our development environments, and we use it to make some small wrappers and tools written in Bash into something portable and reproducible that we can include in development environments that run both on Linux and macOS.

Historically we've just included them inline in our Nix files, but thanks to resholve, we're switching to a nicer system so that they live in separate files that are more pleasant to edit. The "source code" of the scripts lives in the repo as normal bash scripts, but when they get built into the development environment, all command invocations get automatically replaced with hard-coded references to the paths of the relevant executables in the Nix store, the shebang gets pinned to a specific bash version in the same way, and they also get run through ShellCheck. Now we have not only a really nice and quick way to define portable wrappers in our Nix code, but a sane way to manage longer scripts without any portability issues.

So thanks for your cool shell and associated tools and libs!

> Or maybe it's just a harder problem

Fwiw, I think this is true.

> Some people do not like git, but I get the feeling that most people just use it, and get on with their day.

I think one of the other devs on my team probably feels this way. He thinks it's conceptually cool but is somewhat horrified by the complexity and UI. He makes simple uses of it in ways that have precedent on our team, but never really dives in.

> Why the difference with Nix?

Nix didn't have a celebrity author to spur adoption early on, in some ways it can be slow, and I think maybe it isn't as much better than entrenched alternative stacks than Git was as opposed to SVN. The pain of SVN was very acute for the average developer. I'm not sure that any of the pains of dependency hell, stateful configuration management, distribution of portable executables, etc., are quite as acute for the average operator or developer as that. People who feel Nix makes their professional lives easier tend to have come to it after their career has inflicted more specialized pain upon them.

Using Git also doesn't generally (ever?) involve writing code in a Turing-complete language, but to make the best use of Nix, you do have to do that. The paradigm of that language is not very mainstream, either, and although it's generally suited to its domain imo, it certainly has some warts.

[chubot]

I'm glad to hear this! Travis Everett deserves a shout out too for building on OSH, and for being an early adopter :)

Now that Oils has been completely translated to native code (as of last year), we should probably find a way to officially support that functionality.

It is basically built on 'osh --tool syntax-tree foo.sh' ( https://oils.pub/release/0.28.0/doc/ref/chap-front-end.html )

I've also gotten a request for "tree-shaking", which is very related

Thanks for letting me know it's useful!

---

And on reflection I do think Nix has a harder problem, in part because it has to deal with the "outside messy world", where as git just stores files. For example, I noticed that on Debian the set of root packages is actually pretty coupled to apt-get. So any package manager has to have some hacks. Also OS X and libc make that even harder, etc. Some decisions are at the mercy of the OS itself

[pxc]

I suppose one characteristic that Oils, resholve, and Nix share is that each is an ambitious attempt to bridge two worlds in order to propagate recent innovations to actually-existing environments that are entangled with complex legacies: Oils with its two frontends/modes/languages that hope to bring the innovations of PowerShell to settings where Bash is deeply entrenched, resholve in trying to add dependency management to a language that has always fundamentally lacked it and has perhaps a uniquely flexible standard of interop, and Nix in trying to bring insights from implementations of functional programming languages (e.g., garbage collection) and their features (immutability, composability) to Unix filesystem hierarchies.

In a way, I suppose resholve also directly shares a goal of Oils itself— namely, to make shell scripts "more like 'real programs'". YSH pursues this goal through more powerful and flexible language constructs, greater facility with data structures, more ergonomic error messages and other feedback for the user, things like that. Resholve pursues this goal by trying to make it possible for shell programs— even shell programs that rely on a mixture of third-party programs from God-knows-where— can be more portable, less sensitive to changes in the environment, and more amenable to a kind of static analysis of their behavior and dependencies. And both try to achieve their missions in a "conservative" way, letting users retain (or continue to write) code written in the shell language they're most familiar with.

Certainly here on HN, "disruptive" innovation gets a lot more consideration (and praise). But I think that "conservative" innovation of the kind I've just outlined is sometimes even more ambitious and challenging. It's a great thing to see such projects manage to produce interesting and useful results.

So long live Nix, resholve, and Oils!

[amarshall]

Git doesn’t really care at all about the content. Nix does. Really they’re not reasonably comparable at all.

[abecedarius]

Maybe it's better now, but what I ran into in trying twice is that if you're not into installing by "curl | sh", then trying to build from source was an awful experience. It had out of date instructions for installing a whole lot of dependencies. I'd figure out one problem only to run into another, and another. Gave up both times, a few years in between.

[pxc]

There are a few really good ways to install Nix, including ones that people often invoke via `curl | sh`. If you prefer, you can download the exact same installers, and verify the checksums, read their code, etc. You don't have to actually use a different installer just to avoid `curl | sh`.

[chriswarbo]

There are distro packages out there, but those can also come with gotchas; e.g. IIRC Ubuntu's package was configured not to allow `/bin/sh` in sandboxes, which caused some things to break in obscure ways :-(

[rgoulter]

> I honestly wonder why there are such divergent opinions between say git and Nix?

Nix is:

1. difficult & different, where similar-ish tools are straightforward & familiar, (e.g. cloud-init, ansible, vs NixOS; or devcontainers using Dockerfiles, vs nix shells).

2. demands a significant amount of understanding, even for tasks which you'd expect to be easy.

e.g.: git is difficult, but you can get by with rote memorizing 5 commands (& copy-pasting the repo if you mess up). Emacs is difficult, but you're not required to use it. Haskell can be difficult to work with, etc.

I'd say that running `direnv allow` & using nix that someone else has written is unlikely to be difficult. But, having to write your own Nix code can be quite high friction.

> It also seems that Nix's model is less clean

I think nixpkgs is cluttered with organic mess of inconsistent designs.. but I think there's also friction where Nix's ideal package is built with `./configure && make && make install`, and many packages aren't quite that clean.