Hacker News Reader

Comment by wocram | Hacker News Reader

Nix is nice as a catch-all, and especially good when languages like C and C++ don't have popular package managers. It's definitely not better than cargo or pip when dealing with just Rust or Python, but it's definitely relevant when you're building multiple languages.

I would love to see an evolution of nixpkgs with more of a starlark-style for package declarations.

View on HN

This likely wouldn't work on practice. Nix is aggressively lazy, so if you just want a single package, you don't have to evaluate the builds of all 60k+ packages, just the package you wanted and its dependencies.

This just might be me as a functional-programming-maximalist, but I do not like imperative languages for configuration management. You implicitly have to hold the execution state of all actions to know what is going on.

BUILD file evaluation is very similar to nix expression evaluation. I think the bazel 'analysis' phase is equivalent to the nix derivation expansion step

Maybe nix is more lazy, but I would be surprised if nix ends up doing substantially less work than bazel when a single target in a large graph is built.

For managing python dependencies, nix avoids all the headaches of pip, poetry, etc. Builds always work, and one has confidence that they have exactly the same bits as everyone else. nix-shell gives you a virtualenv that also has all your non-python dependencies as well. Instead of dealing with 10 different package managers across a codebase, there's just one.

The trade-off is that it's much harder to select a set of versions with nix, and requires some knowledge of nix lang.

If you can just take all of your packages from a tag of nixpkgs, then that experience is very nice. On the other hand, if you end up wanting a package that is but up to date or missing entirely, that can be a bit more daunting.

Hey good news -- you might be interested in Warpforge: https://github.com/warpfork/warpforge

It's heading in exactly that direction. In fact we specifically want to start using Starlark for module declaration (mind -- optionally. It's still all declarative JSON API at the bottom! APIs FTW!).

We're also going full hermetic and aiming for reproducible-by-default. Those should be "duh" things in modern world. The comparisons with the good parts of Nix should be obvious.

The starlark-adjacent parts are still (very) early, but you'll find some notes about the intention in our Notion already: https://www.notion.so/warpforge/Data-Execution-and-Formulas-...

Get in touch if you'd like to collaborate, we'd be thrilled to have more company working on it, or starting to package things!

I have to say, if it weren't for this comment, reading through the links doesn't make me thing of 'nixpkgs with starlark instead of bash at all'.

Does cargo re-use the same packages between projects? I am asking because cargo is the only build system capable of making me run out of space.

It can if you use a cargo workspace to build all of your projects.

Reply on news.ycombinator.com