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

191–200 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#191

Post by octoberfranklin »

yencabulator wrote: post #190
octoberfranklin wrote: post #189

Earlier quoted context omitted.

Nix uses string antiquotation , not string escaping. It's one of very few languages which has it. And yes, it is sane, very sane. The only sane solution to this problem. Edolstra's thesis advisor was the first to create a scannerless GLR parser: https://en.m.wikipedia.org/wiki/Scannerless_parsing The first versions of Nix used a scannerless GLR parser, because it's the only way to prototype sophisticated features lik…

And that, ladies and gentlemen, summarizes the attitude you'll get from Nix people. By antiquotation you mean evaluating things inside ${}, which is a standard thing in many, many places, including shell and Javascript. Meanwhile, https://nixos.org/manual/nix/stable/expressions/language-val... has gems such as this: > Since ${ and '' have special meaning in indented strings, you need a way to quote them. $ can be esc…

> By antiquotation you mean evaluating things inside ${}, which is a standard thing in many, many places, including shell and Javascript.

No, I absolutely do not.

Re: Nix: Taming Unix with Functional Programming

#192

Post by VTimofeenko »

yencabulator wrote: post #188
euroclydon wrote: post #157

Earlier quoted context omitted.

Yes, although later I learned I could do it in a one-liner. Here nixconfig is a folder with all my nix files: tar -czf - nixconfig | ssh 192.168.1.1 \ 'tar -zxf - && sudo cp -r ./nixconfig/* /etc/nixos/ && sudo nixos-rebuild --show-trace '"${rebuild_flag} ${name_flag}"

If you're ok with building locally and not on the target host, this is simpler: nixos-rebuild --flake .#foo --target-host root@foo --build-host localhost switch

Deploy-rs is a great alternative. It works as wrapper on top of flakes, local (optionally, cross-) building and copying closures to target machine with activation:

https://github.com/serokell/deploy-rs

Re: Nix: Taming Unix with Functional Programming

#193

Post by yencabulator »

VTimofeenko wrote: post #192
yencabulator wrote: post #188

Earlier quoted context omitted.

If you're ok with building locally and not on the target host, this is simpler: nixos-rebuild --flake .#foo --target-host root@foo --build-host localhost switch

Deploy-rs is a great alternative. It works as wrapper on top of flakes, local (optionally, cross-) building and copying closures to target machine with activation: https://github.com/serokell/deploy-rs

These days, that's all included in nixos-rebuild itself, not much need for wrappers anymore. I migrated from Colmena to just nixos-rebuild.

Re: Nix: Taming Unix with Functional Programming

#194

Post by VTimofeenko »

yencabulator wrote: post #193
VTimofeenko wrote: post #192

Earlier quoted context omitted.

Deploy-rs is a great alternative. It works as wrapper on top of flakes, local (optionally, cross-) building and copying closures to target machine with activation: https://github.com/serokell/deploy-rs

These days, that's all included in nixos-rebuild itself, not much need for wrappers anymore. I migrated from Colmena to just nixos-rebuild.

Huh, I guess I was woefully behind on changes to nixos-rebuild. Thanks for the pointer, I will check it out

Re: Nix: Taming Unix with Functional Programming

#195

Post by yencabulator »

VTimofeenko wrote: post #194
yencabulator wrote: post #193

Earlier quoted context omitted.

These days, that's all included in nixos-rebuild itself, not much need for wrappers anymore. I migrated from Colmena to just nixos-rebuild.

Huh, I guess I was woefully behind on changes to nixos-rebuild. Thanks for the pointer, I will check it out

One thing nixos-rebuild doesn't get you is a secrets transmission mechanism. I've been dabbling to build something independent of NixOS/Nix that would still do that neatly...

Re: Nix: Taming Unix with Functional Programming

#196

Post by VTimofeenko »

yencabulator wrote: post #195
VTimofeenko wrote: post #194

Earlier quoted context omitted.

Huh, I guess I was woefully behind on changes to nixos-rebuild. Thanks for the pointer, I will check it out

One thing nixos-rebuild doesn't get you is a secrets transmission mechanism. I've been dabbling to build something independent of NixOS/Nix that would still do that neatly...

May I suggest agenix? It dovetails into my deploy-rs flake setup very nicely and I can track the encrypted secrets in the flake repo.

I keep the "master" key encrypted in pass passing it in a zsh's "=" subshell to agenix.

Re: Nix: Taming Unix with Functional Programming

#197

Post by pdimitar »

rgoulter wrote: post #174
pdimitar wrote: post #171

Earlier quoted context omitted.

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

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

Taking a single sample from recently is just coming across as fanboying and wishing for your desired conclusion to be true. Let's not go in that territory, it's not arguing in good faith.

One of my favorite technologies was "trending" for a bit but then plateau-ed. These things happen. Factors vary but usually fall within a narrow set that's well-known by the "realist" type of people. Many don't like hearing that however, hence endless bikeshedding ensues. No need for that here.

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

And that's exactly what my point is. Nix is nothing like VScode for package management. It's more like an ancient version of VIM whose advocates swear that the months and years needed to learn it well will pay off to eternity. Sorry, I don't mean to bash you or anybody else but I've read forums and GitHub issues. Nix's community demeanor leaves things to be desired.

> Not every tool is well suited to all users.

If you want to "solve" package management, reproducibility et. al. then you should try to cater to all users.

I'll remind you that I really want for Nix to succeed. I hate it how one update command can change files in /etc, /var, /usr and /home. I want isolation! I want trackability! I want to issue a system-wide update command and then check logs for each package updated and which files did it touch exactly. I want that put in a time-travelling database (a la ZFS snapshots) and be able to revert whenever I wish.

These things are hugely important and extremely critical for the future.

In this context just throwing your hands in the air and saying "it's not for everyone" is just not being ambitious enough. I and many others want a replacement for e.g. pacman and apt-get. A complete, 100% replacement, that does everything better.

So far Nix is not that. Until it started closing in on that target then it will remain niche technology for fans.

Obviously so far my vision is not aligning with that of the maintainers. I get that. But I also have plenty of experience and am well within my right to use it to try and predict what traction will their tool get if they do (or don't) certain things.

Re: Nix: Taming Unix with Functional Programming

#198

Post by rekado »

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

This is the old style. See https://guix.gnu.org/en/blog/2021/the-big-change/

Re: Nix: Taming Unix with Functional Programming

#199

Post by rekado »

wdkrnls wrote: post #67
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.

Despite R being the most commonly packaged software on Guix and it being a GNU project and a "common lisp for dummies" lispy language which is used by millions of students, researchers and data scientists, the developers seem to have a noticeable animosity towards it (although not as much as the "snake people"). This makes me sad, as R users would be the first to sign up for what Guix offers if it worked well and the…

I don't follow. Are you saying that Guix developers have animosity towards R or the other way around? In any case I haven't seen animosity on either side.

FWIW I also wrote guix.install, which lets you install R packages through Guix (whether or not they are available in Guix) from within a running R session. I'm maintaining R packages in Guix and woudl like to see more adoption of Guix among R users, so if you have any recommendations on what pain points there are and how to overcome them I'd be happy to hear them.

Re: Nix: Taming Unix with Functional Programming

#200

Post by rekado »

goosedragons wrote: post #178
JHonaker wrote: post #175

Earlier quoted context omitted.

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…

I'm maintaining most of the R packages in Guix and helping hundreds of users at a research institute with their R stuff. I haven't seen any problems like that.

The order of installation does not (and cannot) matter. The most common problem I've seen is that people mix packages from Guix with those built with install.packages that have been linked with incompatible system libraries, which cannot possibly work. This problem is easily avoided --- either by using a container shell (guix shell -C) with a separate toolchain (not the system's toolchain) or by not using `install.packages` (e.g. use `guix.install` instead).

Post reply on HN