
Typing Nix - regnat
http://www.tweag.io/posts/2017-05-23-typing-nix.html
======
atemerev
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. Or the second contender — Haskell. If C-like syntax is desired, the
best contendant is probably Swift.

I cringe every time I have to edit a .nix file (and I have to do it a lot).

~~~
mbrock
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 separators between items instead of after each one; in Nix
each item can always be moved without messing with separators.

I think Nix is an engineering marvel up to and including the language design.
If you can make a better surface syntax and demonstrate it by translating some
significant part of Nixpkgs, I'd be very interested, but I think in general
the language is the way it is because that's what made most sense for the
system's designers.

~~~
codemac
> If you can make a better surface syntax

... [http://gnu.org/s/guix](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.

~~~
mbrock
I dig Guix, but Lisp is also one of the most commonly reviled syntaxes, so
it's hard to say it's clearly better, or that Nix would enjoy more adoption
with S-expressions.

~~~
wcummings
Reviled by people who have never used it.

------
aban
Neat. Somewhat related is hnix [0], a community effort in re-implementing the
Nix expression language in Haskell.

While so far the focus has mostly been on implementing the expression language
as is, hnix being written in Haskell could be attractive for enriching the
language with fancier features:

" _Because now that it 's in Haskell, now that a lot of other hackers could
get involved, we could do things like add optional typing to the Nix
language._" — J. Wiegley

For more on hnix check out Haskell Cast's Episode 13 [1] with John Wiegley.

[0]: [https://github.com/jwiegley/hnix](https://github.com/jwiegley/hnix)

[1]: [http://www.haskellcast.com/episode/013-john-wiegley-on-
categ...](http://www.haskellcast.com/episode/013-john-wiegley-on-categories-
and-compilers)

------
nosefouratyou
There's also Guix in case anyone is interested. It uses Guile/Scheme for
everything instead of Haskell.

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

~~~
geokon
Except GUIX is more of a political project and part of the GNU "stack". It's a
noble goal and I think it's great they're doing it. (It's people doing work on
their spare time, so more power to them!)

But I wonder if that will help or hinder it in the end. It's also unclear to
me what Guile brings other than fracturing the Scheme/Lisp/Racket community
further (there are other Schemes that are older, seemingly just as clean, and
often more powerful). Seems like mostly NIMBYism, but I might be offbase

~~~
mintplant
> NIMBYism

Do you mean NIH syndrome?

~~~
geokon
yeah, thanks for the correction

------
mguijarr
How does Nix compare with conda[0] ? I could not find any useful resource, in
my team we were hesitating between the two, for packages management ; finally
we went for conda because it (seems)is better documented and package
description is easier to write for newbies. And also we are a Python shop, so
other devs felt more comfortable with conda. Personally I prefer Nix, though,
and I wanted to advocate for it but the only main difference I could find is
that Nix sits on top of the kernel (including libc...) whereas conda uses the
system libc.

[0]: [https://conda.io](https://conda.io)

~~~
catern
I wrote this document:
[http://catern.com/posts/deps.html](http://catern.com/posts/deps.html) which
briefly compares both Conda and Nix among other things.

(warning: it's very pro-Nix :) )

~~~
gnufx
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?

There are comparisons with alternatives in at least the propaganda for Spack
and 0install, though the same criticism might apply to those -- I don't
remember.

~~~
catern
rpm and dpkg don't support having multiple versions and implementations of
things simultaneously installed. Not sure what you mean by richer
dependencies.

>You can also do unprivileged installation into a separate root with, say,
fakechroot or PRoot

Yes, but that's the only way to (safely) use such package managers without
privileges; so that's not viable to do for production.

>and you need something like that to install and run Nix unprivileged, don't
you?

Install, yes. Run, no. Setting up Nix does require root, but once it's
installed on a system it can be safely used without privileges by all the
users on the system. That's very valuable in itself, but it's especially
interesting when you consider providing access to a single Nix store over a
network filesystem, or providing it to multiple different virtual machines or
containers.

~~~
gnufx
On RHEL 6 I count eight different packages implementing the MPI standard --
multiple versions of three implementations of essentially the same API --
which can be installed together. The richness is that dependencies are not
generally simply on packages; MPI packages provide things like "mpi",
"openmpi(x86-64) = 1.10.3-3.el7", "libmpi.so.12", and config(openmpi) =
1.10.3-3.el7".

My Guix installation runs using a with privileged access to the store, and Nix
is the same as far as I know. I don't know why Nix would be a particular
advantage on our HPC networked filesystems, and it's not clear it's tenable
for users to be able to DoS the store by installing an arbitrary amount of
software in limited shared space.

It may well be that Nix makes the right set of trades-off against other
possibilities for a given situation, but thta seems at least not completely
clear cut.

------
ris
I'm pleasantly surprised to see so many Nix enthusiasts milling around in this
thread and I'd like to encourage people to step up and do their part in
helping improve and maintain nixpkgs. It's really not that hard, and it's the
main area I would say Nix could do with some improvement. Adopt a package
today!

~~~
akavel
I tried doing some non-trivial contributions, and unfortunately there's
currently some degree of a problem where there are not enough people actively
revieving contributions and having enough authority in the project to be able
to merge with confidence. Is it maybe not enough sponsorship for the project,
compared to its popularity? Or does it not have a person with enough
organisational experience in non-profits?

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

------
sly010
Sure it would be nice to have types for refactoring, but a more useful set of
features would be:

\- baked in fetchurl, fetchgit for easier bootstrapping

\- a functional dsl for rendering filesystem hierarchies - instead of the
find/sed/awk galore. 50% of the time when my nix recipe breaks it's not a nix
syntax issue but something with bash. (reading nix is an exercise in learning
new unix features)

\- drop the channel feature entirely and make releases immutable tar files
with hashes. I use nix as a build system on macos and right now a nix-channel
update is a sure way to break all my builds which is the opposite of nix's
promise

EDIT: formatting

~~~
regnat
For your last point, you don't have to use the channels (which will anyway be
deprecated at some point iirc), and you can pin the nixpkgs version in your
nix files (like it is done in [https://garbas.si/2015/reproducible-
development-environments...](https://garbas.si/2015/reproducible-development-
environments.html))

------
b__d
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!

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

~~~
b__d
Cool, thanks for clarifying :)

------
vesak
I'd like to bring up another sort-of alternative:
[http://habitat.sh](http://habitat.sh)

It's not exactly in the same space as Nix, but not very far from it, either.
In Habitat, you use a language that felt to me quite similar to Arch Linux's
PKGBUILDs, but extended with container-specific things like service ports etc.
Habitat outputs containers that can be started in various orchestration
technologies, like Kubernetes or Mesos/Marathon.

~~~
ungzd
It's interesting and very similar to Nix, but I still didn't figure out
purpose of it, especially why it heavily uses Docker. Many people use Docker
for the same functionality that Nix provides: bundling application with its
dependencies, not for isolating groups of processes from each other.

~~~
vesak
Docker images is one of the supported formats when exporting packages. Others
at the moment are aci, mesos and tarball.

------
dmix
> Configurations in Nix are written in a full-fledged programming language,
> featuring all manner of primitive datatypes (numbers, strings, file paths,
> etc), anonymous records and first-class functions. This is a very big deal
> for writing configurations in the large. Functions allow code reuse and
> abstraction, two crucial ingredients without which writing out
> configurations by hand would become unwieldy.

Off topic but this brings up a good point I've been curious about for a long
time. Does anyone know why VimL is such a terrible language?

It's fascinating to think what potential it could have with a modern language
natively supported like this. The use of Python/Lua etc seem like complicated
hacks on top of it, not to mention the API with tons of globals.

~~~
majewsky
Slightly related: Why does Github call Vimscript "VimL"?

~~~
dmix
It's not just Github, the Vim filetype is "viml". It's a standard name for the
language. Most likely meaning Vim Language.

~~~
majewsky
No, it's not. The filetype is "vim", and the filetype detection code
explicitly calls it "Vim script":
[https://github.com/vim/vim/blob/4670490673ed98502a09b74fbabe...](https://github.com/vim/vim/blob/4670490673ed98502a09b74fbabe785b47e3d289/runtime/filetype.vim#L2384-L2385)

~~~
dmix
You're right, apologies, I was thinking of the Syntastic/Neomake plugin which
both use "VimL" as an identifer, which I had just set up this past weekend and
I mistook that as the Vim filetype identifier.

Regardless Wikipedia says:

> Vim script (also called vimscript or VimL) is the scripting language built
> into Vim.

[https://www.wikiwand.com/en/Vim_(text_editor)#/Vim_script](https://www.wikiwand.com/en/Vim_\(text_editor\)#/Vim_script)

It's also colloquially referred to VimL across the web.

For those looking for an answer, the 3rd result from googling "VimL" is a
question on StackOverflow "Why does VimL suck?" which does a good job of
answering my question:

[https://www.reddit.com/r/vim/comments/1bf672/why_does_viml_s...](https://www.reddit.com/r/vim/comments/1bf672/why_does_viml_suck/)

------
k__
Nice.

Half-OT: How is the new CLI coming along? AFAIK there was an effort to make
Nix usage a bit more like known from other package managers.

~~~
DonbunEf7
There's an effort to make Nix's CLI better, but not necessarily like other
package managers.

The design is at
[https://gist.github.com/edolstra/efcadfd240c2d8906348](https://gist.github.com/edolstra/efcadfd240c2d8906348)

The issue is at
[https://github.com/NixOS/nix/issues/779](https://github.com/NixOS/nix/issues/779)

~~~
k__
One year, and still not closed...

Is this an ongoing process and most of it is already released or is this still
in the making?

------
mellow_
Just a heads up to the author that the link to Nixpkgs is not working, shows
up as [Nixpkgs][nixpkgs]

E: In the paragraph titled "NIX TODAY".

~~~
regnat
Thanks, it should be fixed now

