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

Nix: Taming Unix with Functional Programming

tweag.io

Post reply on HN
Print view View original

131–140 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#131

Post by tomberek »

nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

If something is well-maintained, it is usually pretty easy to make Nix derivation for it. The strict discipline that Nix imposes usually becomes an issue exactly when something is not well maintained or has fundamental issues with how it is managed, but this would be a problem for adoption or port to any other package manager.

Re: Nix: Taming Unix with Functional Programming

#132

Post by VTimofeenko »

euroclydon wrote: post #75

I built my router and NAS from NixOS. It was a mostly pleasant experience. Being able to sit in an IDE on my laptop, and build up a server, incrementally pushing changes to it, with rollback if necessary, was great, and I wouldn't want to go back to anything else. I wrote about the router here. It's pretty heavy on router stuff, and my own thoughts though... https://www.jjpdev.com/posts/home-router-nixos/

Excellent read, thank you! Just in time, I have been eyeing one of those tinyminimicro pcs to replace OpenWRT with Nix.

Could you share more details on push_to_router.sh? Is it a wrapper around calling nixos-rebuild through ssh?

Re: Nix: Taming Unix with Functional Programming

#133

Post by rgoulter »

qudat wrote: post #111
octoberfranklin wrote: post #85

Earlier quoted context omitted.

> most people who just want the software to run don’t want to spend the time learning it these people are not nix's target audience

Relegated to a niche subgroup, I see. There's a significant difference between spending time learning a tool and sinking dozens and dozens of hours into a tool in order to perform tasks that are so basic for other package managers.

I don't think tasks which are basic for other package managers require dozens and dozens of hours sunk into nix to learn.

"Niche subgroup" is about right in its current state. With text editors, VSCode is powerful and accessible to use, but there are power users who prefer to spend time learning Emacs.

With package managers, nix is a power tool. It's not as accessible as it could be. But, the idea of "spend time learning a tool" isn't unusual in software development.

Re: Nix: Taming Unix with Functional Programming

#134

Post by rgoulter »

baby wrote: post #128

Been using nix for a few weeks and while I feel like it really has some great ideas, here are what my pain points have been: - not great documentation, especially for newer features like flakes - nix wants to replace rustup when rustup is already doing great - nix doesn’t seem to work that well on mac. Not sure if it’s our config our that it’s painful on mac in general - the biggest issue: it doesn’t work well with t…

> the biggest issue: it doesn’t work well with tools (vscode, sublime merge, etc.) as you need to launch them within a nix shell and that doesnt work well (at least on mac).

In what sense?

In terms of "some nix shell provides some tools, and VSCode can't see those".. direnv is one way to work with this. e.g. direnv integrates with nix to integrate the nix shell at that path, and a direnv plugin for VSCode etc. can pick up the direnv file, so that it loads the nix shell appropriately.

Re: Nix: Taming Unix with Functional Programming

#135

Post by rgoulter »

whateveracct wrote: post #81
fesc wrote: post #56

Man, there’s a lot of negative comments here. Just to add a different experience: my company loves Nix, it makes it really easy to integrate new tools into the dev/build environment without needing to document which packages, configuration, … a developer needs to apply to their machine manually. There’s nothing like it, really.

Nix attracts whiners - 90% people happy with it are happy using it and not bothering to waste energy arguing with bad attitudes online.

Well, it's easier to be contrarian online.

Though I anticipate better discussion from "nix didn't suit me" than "nix works".

Looking at Nix's community survey, there's been a big growth in the community over the last year or two. I think most who try nix like it, and see it as so obviously a good technology.

Re: Nix: Taming Unix with Functional Programming

#136

Post by viraptor »

infogulch wrote: post #113
SuperSandro2000 wrote: post #101

Earlier quoted context omitted.

The python ecosystem is not a giant mess, its just dependency hell. You need to work with what you get from upstream. > Nix actually integrates all package updates into one channel which nobody else anywhere does If you are using the python system packages then Arch, Debian and probably more are doing the same. > it's even worse because a lot of projects use python as a build dependency (?!) which then cascades these…

Thank you for your input! What do you think about the linked thread? > The python ecosystem is not a giant mess, its just dependency hell. There are dozens (?) of actively used package and environment management systems, with no consistency and no lockfiles, many packages ignore semver, and having multiple versions of a package installed causes weird issues. I'm not sure why "a giant mess" is an invalid descriptor, I…

Semver doesn't really apply here since nix always points at a specific version of each dependency. Multiple package versions are not visible to the same app. And you can include your own lockfile-like list.

So in practice, it's not really a bigger problem for nix than for any other release. If you need to freeze versions for an app, you freeze them. If you don't or if you're packaging a library, you can (usually) rely on automated PR testing to catch breakages and deal with them there.

Re: Nix: Taming Unix with Functional Programming

#137

Post by School-Cotton »

pca006132 wrote: post #63
nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

I think nix probably needs a more beginner friendly documentation as well, by beginner friendly I mean Linux beginners. Beginners will not read through nix pills (assuming they can understand it) before trying nix, they will just give up. And there are a lot of Linux users who don't have much technical knowledge about how binaries are being linked, etc. I think the ecosystem is now mature enough for beginner users to…

Why is it necessary for Nix to be accessible to Linux beginners?

Sure it’d be nice to have, all else being equal, but I don’t see how it helps advance the goals of the project for the people who are using it today.

Re: Nix: Taming Unix with Functional Programming

#138

Post by infogulch »

viraptor wrote: post #136
infogulch wrote: post #113

Earlier quoted context omitted.

Thank you for your input! What do you think about the linked thread? > The python ecosystem is not a giant mess, its just dependency hell. There are dozens (?) of actively used package and environment management systems, with no consistency and no lockfiles, many packages ignore semver, and having multiple versions of a package installed causes weird issues. I'm not sure why "a giant mess" is an invalid descriptor, I…

Semver doesn't really apply here since nix always points at a specific version of each dependency. Multiple package versions are not visible to the same app. And you can include your own lockfile-like list. So in practice, it's not really a bigger problem for nix than for any other release. If you need to freeze versions for an app, you freeze them. If you don't or if you're packaging a library, you can (usually) rel…

The thing that you and sibling miss is that this only applies to the one direct dependency on a package, but not on dependencies required by that package. For that you have to work with any build and dependency resolution system that the package or its author uses, and you're up a creek without a paddle if the author doesn't care to help you debug your own system.

Re: Nix: Taming Unix with Functional Programming

#139

Post by Ericson2314 »

jnxx wrote: post #15
nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…

> minimalistic

The Nix language is far more minimalistic than any Scheme. I have nothing against Scheme but let's be clear, Nix out-Schemes Scheme in this regard.

Re: Nix: Taming Unix with Functional Programming

#140

Post by Ericson2314 »

SuperSandro2000 wrote: post #95
pca006132 wrote: post #63

Earlier quoted context omitted.

I think nix probably needs a more beginner friendly documentation as well, by beginner friendly I mean Linux beginners. Beginners will not read through nix pills (assuming they can understand it) before trying nix, they will just give up. And there are a lot of Linux users who don't have much technical knowledge about how binaries are being linked, etc. I think the ecosystem is now mature enough for beginner users to…

Nix is a programming language and there is no visual editor for it yet.

I think we could do a GUI for a subset; would love to do that someday.
Post reply on HN