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

181–190 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#181

Post by jnxx »

lamontcg wrote: post #166
jnxx wrote: post #144

Earlier quoted context omitted.

> There has to be some kind of release valve for software to evolve and break backwards compatibility. You kinda insinuate that breaking backwards compatibility is kinda necessary at times. This is not the case. Projects like * the Linux kernel, or * the GNU C library, or * the Numeric -> Numpy transition around Python 2.0, or * Common Lisp (which is much older than Python) adopting Unicode are good examples that thi…

The problem with most open source software that is in package managers is that it is usually done by one person. It isn't started by someone with a decade of interface design, it is often their first large important project, they DONT do the well designed interfaces because they haven't made the mistakes in interface design yet which they'll eventually learn from. And then when it comes to backwards compatibility it…

I did not say that hobbyist packages which are used by few people and are unstable experiments should be kept stable at all costs.

But you see the linked discussion about stability in Nix is about packages like opencv, pillow, boost, pytorch, tensorflow, kubernetes, and I would expect them to behave professional.

And as said, as long too few people actually respect semver, it is pointless to suggest to use it, especially if the authors of a package do not know what a breaking change is, do not know how to avoid them to happen, and do not have a documented and specified API in some way. If you don't have an API, you can't use semver.

Re: Nix: Taming Unix with Functional Programming

#182

Post by jnxx »

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.

I do not complain. Complaining is like "Uncle Bert was totally drunk again and fell down the stairs and broke is arm and I expect him to change in order to make me happy." Or "Frank did lend my car again and damaged it, and I told him again that I do not like that".

What I do is observing things and drawing consequences. "Sorry, Frank, you can't have my car." And: "Well, Uncle Python does of lot of breaking changes, so I do not better use it for long-lived projects which I do not want to constantly fix. Maybe I could have a look around what languages do manage this better?"

This is not, I think, an attitude I am alone with. For example, the Python2 / Python 3 breakage led Konrad Hinsen, an earlier contributer to Numpy and Scientific Python, to explore Racket as a language for scientific computing:

https://khinsen.wordpress.com/2014/05/10/exploring-racket/

And more concretely, and perhaps pragmatical, when I start a project or include a library, I am critical about the stability the environment offers. For example, in some situation I used gevent in place of newer and perhaps fancier solutions because it was stable across the Python2/Python3 version bump, and I did not want neither myself or my coworkers to need to re-write that part.

This does not mean I stop to use Python altogether. It is still useful for many applications. However for writing new library code, I will rather use something that is more likely to be stable.

Re: Nix: Taming Unix with Functional Programming

#183

Post by JHonaker »

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 was too frustrated by the insistence on libre purity by the main Guix channels, even if I think it is superior software, so I switched to Nix (and actually went fully NixOS after a month or so).

I had R package compilation issues on 4.2 as well, but I also had them on my Windows work machine. I'll try to test things out and see if I can figure out if it's still an issue.

Re: Nix: Taming Unix with Functional Programming

#184

Post by yencabulator »

grumbel wrote: post #21
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. It already has one with the 'nix' command, it just needs to be manually enabled under 'experimental-features', but once done there is basically no reason to ever touch any of the old commands.

Which is not without its own warts, in ways that just don't give me any hope. Simplest example:

nix run nixpkgs#cargo --help

gives you a pager viewing the manpage of `nix run`.

Re: Nix: Taming Unix with Functional Programming

#185

Post by mikepurvis »

senorsmile wrote: post #154
mikepurvis wrote: post #35

Earlier quoted context omitted.

Yup. I started with Nix a little over a year ago on Nix 2.3, and have only ever used flakes and the new CLI. It's complete from my point of view— the main issue is just that the pills and all the official documentation still refer to the old commands. I wish they'd flip it over to being the default and update the docs. I know that's not trivial, and it's hard when all the long-time community members have the legacy c…

I started with a single system on NixOS around February of this year. I just recently saw an example of `nix search` instead of `nix-env -qaP`. I haven't seen any documentation for all of this new stuff. Any place to go, or do we just have to go read the source code?

I think it's basically just the man pages online, but I've found this resource to be pretty helpful:

https://nixos.org/manual/nix/stable/command-ref/new-cli/nix....

Re: Nix: Taming Unix with Functional Programming

#186

Post by yencabulator »

otabdeveloper4 wrote: post #104
octoberfranklin wrote: post #86

Earlier quoted context omitted.

Nix is a metaprogramming language for bash. The metalanguage is indeed purely functional. The object language (bash) isn't.

Right. You still end up mostly writing bash scripts when wrangling Nix. It's not some sort of ivory tower Haskelish hermetic ecosystem, it's just a very nice way to make bash scripting sane.

I don't think I'd call adding yet another layer of escaping syntax "sane".

Re: Nix: Taming Unix with Functional Programming

#187

Post by yencabulator »

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…

That sounds like a dependency not detected by the kludge that at least Nix uses where it essentially greps everything for path names that look like dependencies.

Said differently:

- build recipes A and B add paths to the store

- B uses paths from A, but in a way that the dependency tracker does not notice

- if the paths from A were instantiated in the system first, B works by luck

Re: Nix: Taming Unix with Functional Programming

#188

Post by yencabulator »

euroclydon wrote: post #157
VTimofeenko wrote: post #132

Earlier quoted context omitted.

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?

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

Re: Nix: Taming Unix with Functional Programming

#189

Post by octoberfranklin »

yencabulator wrote: post #186
otabdeveloper4 wrote: post #104

Earlier quoted context omitted.

Right. You still end up mostly writing bash scripts when wrangling Nix. It's not some sort of ivory tower Haskelish hermetic ecosystem, it's just a very nice way to make bash scripting sane.

I don't think I'd call adding yet another layer of escaping syntax "sane".

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 like antiquotation without going completely mad. Once the syntax was completely locked down it was rewritten with a separate scanner and LR(something) parser, but they're intricately entwined. The scannerful, non-GLR parser is faster but basically frozen and extremely difficult to modify. Fortunately Nix's syntax has been exceptionally stable for the last decade or more.

True string antiquotation is a feature that every language should have, but unfortunately with current technology it forces you to choose between a slow parser or a fast parser that's almost impossible to modify.

Some languages have "string interpolation" which is a weaker, more fragile form of antiquotation.

Re: Nix: Taming Unix with Functional Programming

#190

Post by yencabulator »

octoberfranklin wrote: post #189
yencabulator wrote: post #186

Earlier quoted context omitted.

I don't think I'd call adding yet another layer of escaping syntax "sane".

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 escaped by prefixing it with '' (that is, two single quotes), i.e., ''$. '' can be escaped by prefixing it with ', i.e., '''. $ removes any special meaning from the following $. Linefeed, carriage-return and tab characters can be written as ''\n, ''\r, ''\t, and ''\ escapes any other character.

Post reply on HN