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

Typing Nix

tweag.io

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Typing Nix

#121

Post by gnufx »

wcummings wrote: post #120
gnufx wrote: post #115

Earlier quoted context omitted.

Does something actually stop you packaging proprietary binaries, perhaps privately, for Guix? It's clearly better to say No, but CUDA is a case where that's difficult. (I don't see what's wrong with adopting sexps to avoid dealing with custom syntax -- quite the opposite,)

The kernel it ships with won't load blobs.

OK, there's a distinction between the GuixSD free software distribution and Guix package management. I'm surprised you can't build and use a non-linux-libre kernel with GuixSD, though; that presumably excludes even free additions, like Lustre, unless someone has done the forward porting work. (One of the recent HPC-ish presentations on Guix mentioned nvidia stuff -- I don't remember which.)

Re: Typing Nix

#122

Post by regnat »

gnufx wrote: post #114
catern wrote: post #21

Earlier quoted context omitted.

I wrote this document: http://catern.com/posts/deps.html which briefly compares both Conda and Nix among other things. (warning: it's very pro-Nix :) )

Not to put down Nix, but some of the arguments about other systems have counterexamples. For instance, it's common in rpm or dpkg distributions to have multiple versions and implementations of things, and richer dependencies than simply on packages. You can also do unprivileged installation into a separate root with, say, fakechroot or PRoot, and you need something like that to install and run Nix unprivileged, don't…

You can install Nix in a totally unprivileged fashion, without having to use hacks such as PRoot, you just need to configure it to use a directory you have write access to instead of /nix. But doing so breaks the ability to use the official binary caches (because relocating the store requires recompiling packages), and this isn't particular to nix (I remember that portage at least does this too, and probably some others). The interesting part is that with an installed deamon, the admin can allow users to install packages in their own profile, while still benefiting from sharing of dependencies and other niceties.

About the multiple versions, the problem with "classical" package managers is that you have to do some manual renaming to ensure that both versions won't be installed in the same place in the file-system, which is tedious and doesn't scale well. Furthermore you may encounter some problems because both will be visible at the same time if the packager isn't careful enough. For example, if a software X has a dependency of libfoo2.1 and you happen to have libfoo3.1 also installed, the installation script for X may use libfoo3.1 instead of libfoo2.1, in which case you risk to encounter bugs because X hasn't been tested against libfoo3.1.

Re: Typing Nix

#123

Post by b__d »

bennofs wrote: post #66
b__d wrote: post #4

Funny: Nix is short (or colloquial) for "nichts" in German which further means "nothing" in English. So the CTA "Get Nix" is kinda funny for German speaking people :) PS: Greetings from Austria!

I believe that this meaning is even intentional, the original author of nix (Eelco Dolstra) is from the Netherlands. The name comes from the fact that by default, nothing is available in build environments in nix.

Cool, thanks for clarifying :)

Re: Typing Nix

#124

Post by KirinDave »

mbrock wrote: post #36
atemerev wrote: post #6

I love Nix. NixOS is my primary development operating system. However, the Nix language itself is syntactically ugly , and this proposal makes it even uglier. Parentheses, sigils and special characters (esp. semicolons) are line noise — the less of it the better. Why they wouldn't take the most (syntactically) beautiful functional programming language out there — Standard ML? It would work perfectly for such a task.…

I love the Nix language and I generally distrust aesthetic feelings about programming languages. Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example. The multiline interpolated strings in Nix are extremely much better than in SML or Haskell. The way records and arrays are written is great: SML and Haskell both suffer from the tedious problem of using separ…

> Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example.

Purescript's extensible row types handle this process elegantly and if Nix takes a cue from that, it will work great.

Re: Typing Nix

#125

Post by civodul »

The problem with Nix in terms of typing is that it relies a lot on key/value dictionaries ("attribute sets" in Nix parlance). These data structures are dynamic in nature. All a static type checker can say is "yeah this is an attribute set". In addition, Nix does not offer a way to define new disjoint data types.

Conversely in Guix most of the data structures are disjoint record types. Scheme (the implementation language of Guix) is dynamically-typed, but there are sanity checks we can do on records both at macro-expansion time and at run time, such as checking whether all the required fields are defined and no extra field is passed. Concretely, this means that users get clear syntax errors or run-time type errors.

Nix and Scheme are both dynamically typed, but they have a different typing story.

Disclaimer: Guix hacker here.

Re: Typing Nix

#126

Post by civodul »

akavel wrote: post #94
davexunit wrote: post #8

Earlier quoted context omitted.

I think that all the efforts to fix or re-implement the Nix language have vindicated Ludovic, the Guix maintainer, who chose an existing general-purpose language instead.

But Scheme is untyped too AFAIK - isn't it? So it'd require the same degree of "fixing" as long as we're talking about the discussed article.

As I explained in another comment, Scheme is indeed dynamically-typed (like Nix), but it's also strongly typed: one can define new data types, they are disjoint, and there can be no casts and the like. In Guix "packages" and "operating systems" are different types, you get a type error if you use one instead of the other; in Nix both are "attribute sets" (key/value dictionaries.)

I think the one-type-fits-all ("attribute sets") vs. strong typing (disjoing record types) axis matters more than the static vs. dynamic axis here because most of the code (OS config files, package definitions, etc.) is loaded dynamically.

Re: Typing Nix

#127

Post by codemac »

jancsika wrote: post #97
codemac wrote: post #55

Earlier quoted context omitted.

> If you can make a better surface syntax ... http://gnu.org/s/guix Lisp is pretty good at lists. The only important language is the derivation language sent to the daemon. Nix spends so much time building up inputs... for shell scripts. I always felt like they would have been so much more successful if they chose some other, more popular language to generate derivation.

Is it possible to write a guix package that includes code which redefines the package object?

Yes!

http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/...

You'll see here that the package emacs-minimal actually inherits from the emacs package definition, and then all fields afterwards are essentially overwrites of whatever was in the emacs package.

Unfortunately, I just noticed that the manual alludes to this, but actually never explicitly documents it in the "Defining Packages" section :/

Re: Typing Nix

#128

Post by teddyh »

Arnavion wrote: post #98
weberc2 wrote: post #95

Earlier quoted context omitted.

JavaScript doesn't (didn't?) let you put a trailing comma in function parameter lists, annoyingly.

Made legal in ES2017.

But not in JSON, since that is based on ECMA-262 3rd Edition from December 1999.
Post reply on HN