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

171–180 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#171

Post by pdimitar »

rgoulter wrote: post #167
pdimitar wrote: post #165

Earlier quoted context omitted.

Spending time to learn a tool is a standard requirement in our profession. Nobody but the laziest ones has a problem with it. Programs like Nix, Emacs, VIM, Git -- they require a lot of time sunk into them to sometimes get even to basic productivity. The latter is not okay. While I think it's unavoidable for Emacs and VIM, I've seen enough Nix and Git recipes and confusing command line aliases to conclude that Nix (a…

> To me it looks like Nix is firmly headed in the direction of a yet another tool with a very good idea whose authors don't want to make it more usable and thus it remained a niche curiosity for people with too much free time. What gives you the indication things are headed in the wrong way? I think things are heading in the right direction. The last year has seen nix flakes release to the stable nix version. Flakes…

> What gives you the indication things are headed in the wrong way?

Because it started swinging in the direction of "you are not the target audience" while at the same time raving about how it's the solution to the software packaging and distribution problems -- which, pardon if mistaken, are very ambitious and big goals that affect VERY different groups of people.

Telling any of them "it's not made for you" is not doing their cause any favors.

One example: documentation and onboarding. A good amount of guides, both official and out there, still use the old-ish syntax while `nix ` has been a thing for a while now.

...Also "flakes", "pills", really? Can we finally grow up and start using proper terminology? The cutesy jargon must go. Forever. This is not a kids game and not a hobby project anymore. You're writing software with extremely ambitious goals. Show some professionalism. I can close my eyes on that and have done so many times but I've personally known a good amount of engineering leaders that would deny usage of software on that basis alone.

Nix got to a part of its lifetime where marketing and onboarding have to be heavily prioritized and its community doesn't seem very keen on it. That dooms it to obscurity from where I am standing because I am one of those programmers that visit the website and are like: "What is this? Oh, that. How do we start? Like so? Cool. Oh... an error on the second command, seriously? OK, OK, let's just Google it -- huh, nothing. Yeah, frak that, bye".

The above has to be mercilessly chased and resolved at every occasion, aggressively. If not, Nix is going to be the next Snap / Flatpak.

And I really want to make it super clear if you're still with me: I want Nix to succeed. For now though I view it as a nascent tool that still has long ways to go. And I really wish they started learning from the mistakes of Git (confusing CLI, big docs that don't help one get onboarded quickly). But so far it's not looking good on these points.

Admittedly I last checked it out 7-ish months ago. I'll try checking it out every 3 months or so from now on. And I hope I am wrong.

Re: Nix: Taming Unix with Functional Programming

#172

Post by baby »

rgoulter wrote: post #134
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 pi…

I tried everything from direnv (with the nix direnv thing and a diverse direnv extensions for vscode) to opening vscode from a flake dev shell, nothing works on my mac

Re: Nix: Taming Unix with Functional Programming

#173

Post by baby »

ParetoOptimal wrote: post #168
rgoulter wrote: post #134

Earlier quoted context omitted.

> 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 pi…

Vscode doesn't let you specify plugin load order and nix-env-selector needs to load before anything else or you can have problems last I checked.

Ah that might be why I had these problems. Do you know what a solution could be?

Re: Nix: Taming Unix with Functional Programming

#174

Post by rgoulter »

pdimitar wrote: post #171
rgoulter wrote: post #167

Earlier quoted context omitted.

> To me it looks like Nix is firmly headed in the direction of a yet another tool with a very good idea whose authors don't want to make it more usable and thus it remained a niche curiosity for people with too much free time. What gives you the indication things are headed in the wrong way? I think things are heading in the right direction. The last year has seen nix flakes release to the stable nix version. Flakes…

> What gives you the indication things are headed in the wrong way? Because it started swinging in the direction of "you are not the target audience" while at the same time raving about how it's the solution to the software packaging and distribution problems -- which, pardon if mistaken, are very ambitious and big goals that affect VERY different groups of people. Telling any of them "it's not made for you" is not d…

> Nix got to a part of its lifetime where marketing and onboarding have to be heavily prioritized and its community doesn't seem very keen on it.

As far as I can tell, Nix is growing pretty well. The results from the last community survey indicated that most of the users started using it within the last few years.

> And I really want to make it super clear if you're still with me: I want Nix to succeed. For now though I view it as a nascent tool that still has long ways to go.

Perhaps by analogy: if apt-get is like notepad, and nix is like emacs/vim, it'd be neat for something like VSCode.

I think rough edges like "nix isn't nice to use for ", etc. would be good to sort out. -- But, yeah, that the documentation is rough, and the onboarding is harsh, were some of the big pain points identified in the community survey.

> Telling any of them "it's not made for you" is not doing their cause any favors.

Not every tool is well suited to all users.

I wouldn't recommend Arch or Gentoo linux distributions to someone who doesn't want to spend time tinkering, or spending time figuring out why something broke. I'd recommend Debian instead.

I wouldn't recommend Rust to a team which can't afford the time to train developers. Whereas, Go is a much simpler language that's easier to pick up.

In its current state, Nix isn't well suited to "I just want things to work, I'm not interested in a package manager more involved than apt-get".

Re: Nix: Taming Unix with Functional Programming

#175

Post by JHonaker »

goosedragons wrote: post #16
jnxx wrote: post #14

Earlier quoted context omitted.

I am not sure, but it is possible that R want to be its own package manager which interferes with Guix? A similar problem seems to appear in Python, where there on Distributions like Debian there is kind of a struggle which package manager - the system-defined packages, or the user-defined ones like pip - have the last word. I have used Guix a bit with Common Lisp libraries, and that works like a charm. I also found…

R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.

This… shouldn’t happen. The whole point of Nix and Guix is that you can have multiple versions of the same thing in different dependency chains. It’s designed to avoid precisely this issue. If a package relies on something it should be built before hand, and if and only if it’s identical (well content addressable vs inputs is a whole other thing) it will share the dependency.

Would you mind sharing exactly what the R packages you were having problems with were?

I wonder if you were relying on globally installed versions of things instead of an R installation that had the packages wrapped into its environment. I’m more familiar with Nix, but you’ll typically see people do something like add this to a local project build input or development shell:

    r-lang.withPackages with rPackages; [ r-ggplot2 r-data-table ];
Rather than

    nix-env -iA r-4.2 r-ggplot2 r-data-table
Or the Guix equivalent

    guix install r …
Globally installing things can lead to situations where you think it should work but if you really think about how the store dependencies work, they don’t.

Re: Nix: Taming Unix with Functional Programming

#176

Post by lmz »

SuperSandro2000 wrote: post #164
jnxx wrote: post #150

Earlier quoted context omitted.

Which is a good thing because most users do not want to configure and program Guix stuff all the time. Many will only use it every few months, and probably don't want to learn syntax and semantics again and again. Extreme terseness like APL or math notation is fine if you work with something all the time. However for infrastructure code and especially build systems, I think readability as well as robustness are much…

It's hard for me to find a good point about the verboseness and repetition of for example https://git.savannah.gnu.org/cgit/mediagoblin.git/tree/guix-...

It's scheme. I assume you can macro that repetition away if you really want to.

Re: Nix: Taming Unix with Functional Programming

#177

Post by btschaegg »

lamontcg wrote: post #170
btschaegg wrote: post #119

Earlier quoted context omitted.

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 wi…

Rust has corporate sponsorship and a very experienced team of developers. You won't get that level of attention to detail and commitment to getting the design right up front, and the willingness to maintain old APIs in the name of backwards compatibility in a single-person open source project published into a package manager done on someone's free time. So you are probably arguing for very thick standard libraries wh…

> So you are probably arguing for very thick standard libraries which are maintained by the core language team, […]

No, I'm not arguing that Nix should do anything in particular.

All I was saying is that the "we have to get it right the first time without much feedback" way obviously isn't the only one and there's empirical evidence of other working models.

As for PRs and so on you're really putting words in my mouth, and frankly, I don't like it. Just so you know. I have never made PRs to core Nix, but for Nixpkgs I have only had a good experience so far.

---

Edit: Or are we really talking Python? In that case, I could even less comment on PRs. But: Python has a large stdlib (it's "batteries included", after all). But also, Python often has found good ways to deal with its warts.

And I hope I don't have to argue that Python3k wasn't worth the trouble, right?

And frankly, there, I'd argue that growing to the point that python has you'll have to reexamine some more ways to gather data about community interest, for example.

From the outside, the process around the walrus operator and Guido leaving the BDFL post looks like a prime issue of either not having enough "wild information" early on or of the final decision ignoring a vocal part of a huge language community.

Re: Nix: Taming Unix with Functional Programming

#178

Post by goosedragons »

JHonaker wrote: post #175
goosedragons wrote: post #16

Earlier quoted context omitted.

R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.

This… shouldn’t happen. The whole point of Nix and Guix is that you can have multiple versions of the same thing in different dependency chains. It’s designed to avoid precisely this issue. If a package relies on something it should be built before hand, and if and only if it’s identical (well content addressable vs inputs is a whole other thing) it will share the dependency. Would you mind sharing exactly what the R…

Yeah and that's part of what made it so confusing.

Even in a pure Guix shell it only worked in a specific order. Packages were R, TMB (an R package), gcc-toolchain, gfortran-toolchain and make. You need to be able to compile C++. If was R specified before the toolchains then nothing could be compiled with TMB. I forget the exact error. I did not have those packages globally installed and I saw the same problems with Guix SD and a foreign distros.

But with R 4.2 I ran into a different problem and never fixed, that anything using the RcppEigen header would not compile.

And I don't believe Guix has the same wrapping packages into R style as Nix.

Re: Nix: Taming Unix with Functional Programming

#179

Post by phaer »

pxc wrote: post #49
eulenteufel wrote: post #46

Earlier quoted context omitted.

It's nice that there is a workaround, but passing build options is not something that should require a library. There should be a well documented standard way to do it.

Agreed. For most early adopters of flakes, flake-utils-plus is the de facto standard solution. It would be good to see something like it built into Nix or Nixpkgs and blessed in the official docs, as the flakes feature approaches completion.

Flake-utils, flake-utils-plus, https://flake.parts/, https://github.com/divnix/std/ and others :D

Re: Nix: Taming Unix with Functional Programming

#180

Post by jnxx »

lamontcg wrote: post #118
infogulch wrote: post #115

Earlier quoted context omitted.

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 c…

> they're not complaining about packages just violating SemVer so I don't think your interpretation makes sense.

Packages regularly violate semver, to the degree it becomes a cargo cult.

It is funny that at the one hand side, people say that keeping backward compatibility is too difficult for normal package authors and contributors, and on the other hand side suggesting that using semver would improve this.

In order to actually use semver, one needs to know what backward compatibility is, what kind of changes break it, and how to make sure that this breakage does not happen. It is not that difficult. But also, semver require stability against an API, so one absolutely needs to have a clearly documented API of some sort, because otherwise, if there is absolutely nothing specific you promise, how could one expect you to keep it?

And further more, major packages should actually respect semver if they claim to use it, and not do breaking changes with minor version numbers, like for example boost does. Actually, I think if somebody uses a three-element version number and does not strictly adhere to semver, it should come in a popup box in front of every download link, because these three-part version numbers somehow imply that the package uses semver, and this in some cases (like boost) is a false promise.

And before somebody throws in that it is not *his* package that is breaking semver, but some dependency that his package happens to use: No. If you use dependencies, you are responsible for their behavior, because otherwise, one could always shift the blame somewhere else. If a dependent package breaks backward compatibility and your package is a library package, including it is a breaking change, because backwards (in)compatibility of dependencies which have visible effects (as is the case in all Python library modules, as has been discussed) is a transitive property which travels up the dependency graph. If you include visible breaking changes, then your package introduces a breaking change, and cannot honour semver without bumping the major version number.

Post reply on HN