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

111–120 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#111

Post by qudat »

octoberfranklin wrote: post #85
bogota wrote: post #59

Earlier quoted context omitted.

I dont think anyone is being negative at least not the top level comments i read. I like nix but i gave it a test run at my company and no one could figure out how to make any change that wasn’t a copy and paste of what i had done. The docs don’t help much unless you really go diving into them and most people who just want the software to run don’t want to spend the time learning it. I don’t blame them. This is a ver…

> 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.

Re: Nix: Taming Unix with Functional Programming

#112

Post by pxc »

idealmedtech wrote: post #109

Back in college, the engineering school had a farm of Linux servers from which you could access all your documents, as well as log in to your account from any number of computer labs around campus. Back when I was first learning Linux (not that long ago, 2008), I fell in love with how many things you could customize, and really create your own experience. When I got to college, I wanted to replicate this ability (ins…

This is also how I got into Nix! I just used a 'normal' Nix install with a fake chroot (pivot_root/proot) environment, though, so I didn't have to build from source and I got to leverage the binary caching. There were some quirks, but overall it worked well.

Re: Nix: Taming Unix with Functional Programming

#113

Post by infogulch »

SuperSandro2000 wrote: post #101
infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

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 guess it's just arguing semantics.

Re: Nix: Taming Unix with Functional Programming

#114

Post by lamontcg »

infogulch wrote: post #108
lamontcg wrote: post #105

Earlier quoted context omitted.

> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and…

Yes they've invented that: It's called bumping the major version.

The parent comment is complaining about Python 2/3 breakage which was a major version.

Re: Nix: Taming Unix with Functional Programming

#115

Post by infogulch »

lamontcg wrote: post #114
infogulch wrote: post #108

Earlier quoted context omitted.

Yes they've invented that: It's called bumping the major version.

The parent comment is complaining about Python 2/3 breakage which was a major version.

Not exactly, they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.

Re: Nix: Taming Unix with Functional Programming

#116

Post by alch- »

hamandcheese wrote: post #89
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.

Are you hiring?

I'm not GP, but my company's experience[0] is the same, and we're definitely hiring. Seeing Nix in the tech stack was one of my reasons for applying :)

[0] https://www.channable.com/tech/nix-is-the-ultimate-devops-to...

Re: Nix: Taming Unix with Functional Programming

#117

Post by nixpulvis »

alberth wrote: post #37
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…

> Nix needs a new porcelain interface for it's CLIs. The analogy I'd use is that Nix needs what "Github did for Git". Meaning, git is actually unnecessarily complex. But Github made git easy and accessible.

No doubt that is needed too! The "human" interface, if you will (that which sits on top of the porcelain).

Still, I think Nix could make a better interface for us power users.

Re: Nix: Taming Unix with Functional Programming

#118

Post by lamontcg »

infogulch wrote: post #115
lamontcg wrote: post #114

Earlier quoted context omitted.

The parent comment is complaining about Python 2/3 breakage which was a major version.

Not exactly, they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.

Well they should clarify because they cite the example of the 2/3 breakage which is a major version break, and they're not complaining about packages just violating SemVer so I don't think your interpretation makes sense.

It also certainly wasn't what I was responding to, and responding with "hurr durr major versions" like I've never heard of them before is just mildly insulting (and kind of insulting to the parent comment by proxy)

Re: Nix: Taming Unix with Functional Programming

#119

Post by btschaegg »

lamontcg wrote: post #105
jnxx wrote: post #76

Earlier quoted context omitted.

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and…

I don't disagree, but it doesn't only have to go in this one direction. One of the most interesting things about Rust for example is how it tackles experimental implementations and has concepts in the compiler etc. that make unstable language features "first class". I'd say this will definitely yield better results than "well a couple of guys hacked around on some prototype forks of a compiler, and now we're stuck with the result".

Of course, they also make very impressive backwards compatibility guarantees for stable stuff (cf. Rust's "editions").

Re: Nix: Taming Unix with Functional Programming

#120

Post by revscat »

noahmasur wrote: post #90
revscat wrote: post #54

Earlier quoted context omitted.

We use Brewfiles to install binary dependencies needed by various projects. This is only for developer’s machines, but it’s lightweight and fast: `brew bundle` and you’re done.

What happens when you have two projects that use two different versions of the same dependency? With Nix, you can "install" many different versions of the same program side by side in the store, and then "activate" the one you need at runtime (or with direnv).

Has never happened. I know this is something that is given as a benefit of Nix, but I have personally never encountered the situation. For every project I have worked in professionally their tool chain was standardized enough that the situation never arose.

If parallel installations like you describe is a requirement — and I’m sure that it is — then Nix looks like it could help. That’s just not something I have ever found myself needing.

Post reply on HN