
Nix Language Primer - binaryphile
http://www.binaryphile.com/nix/2018/07/22/nix-language-primer.html
======
Harkins
Does anyone know the rationale for creating Nixlang? Guix's use of Scheme
proves there isn't a novel feature unavailable elsewhere, so it seems like a
lot of wasted effort to implement a language that will likely only ever be
used for one suite of programs. (And tooling; though almost none exists now,
making the choice even more expensive.) I've tried to find one, but "nix" is a
difficult thing to google for given the couple decades people have used it as
a catchall term for unix and unix-like operating systems.

~~~
otabdeveloper2
Nobody wants an arbitrary complex program for describing some trivial build
steps. A programming language here is an anti-feature.

Ideal would be some DSL that isn't even Turing complete, but that's not
practical at the moment. Maybe we'll get there some day.

~~~
X6S1x6Okd1st
Really what no one wants is a build step that takes forever. I'm more upset
about how long nix-env -i takes than what the computational complexity of the
programming language is

~~~
Nullabillity
nix-env -i is slow because it has to evaluate every package definition. nix-
env -iA is way faster.

------
zimbatm
A few correction on the otherwise good article:

* Nix 2.0 includes the repl. Just run `nix repl`

* The URL literal returns a string

* It would be good to explain how the `<...>` notation resolves paths from the NIX_PATH. For example `<nixpkgs>` looks for the `nixpkgs` key in `NIX_PATH=nixpkgs=/path/to/channel`

~~~
binaryphile
Thanks for the tips. We're still running on 1.11 because of problems with the
recent glibc updates not matching the kernels in our deployment environment.

------
rufugee
I switched all of my machines to NixOS for a few months. It was a wonderful
experience being able to keep all my environments in sync. Nix the language is
one reason I reverted to Ubuntu a few weeks ago. It just didn't mesh well with
me....so when the inevitable problem occurred, it was a pain to deal with.

Other pain points:

\- the NixOS learning curve is steep. There are two many tools with too many
obscure options with sometimes overlapping features.

\- small group of maintainers with no real documented security process...just
an assurance that they path as quickly as possible

\- many packages are old if they're not mainstream

I would love to see the concept of Nix reimplemented in a non-niche language
without the fsf zealotry... I'd switch my company to something like this in a
heartbeat. I think there's a real business opportunity for someone willing to
take that on.

~~~
zzzcpan
Imagine if all the right ideas from nix were taken out and combined with
supervision trees, we would have super reliable distros and PaaS style one
click infrastructure.

------
nwmcsween
I don't understand why any languages exist for describing packages, its a
layer above describing real dependencies like with make, ninja, etc. Just have
an os written in something like premake but with a nicer DSL.

~~~
zimbatm
It allows to have some guarantees around the evaluation. The Nix expression
language enforces things like not allowing arbitrary network access during
evaluation. This is hard to do in a general-purpose language where network and
file access are usually backed in.

~~~
nwmcsween
This is easily done by chain-loading and system()

------
malkia
There is also [https://jsonnet.org/](https://jsonnet.org/)

~~~
arianvanp
Yep they're pretty similar in goals, (and syntax?) except for that nix has
built in support for derivations as a language feature. Nix is a language for
derivations first a language for configurations second. Jsonnet is only a
configuration language.

------
spacesuitman2
Why the need for another new language? Why not just use Guile or Scheme
instead?

~~~
k__
Probably the same reason why Guile or Scheme didn't get as wide-spread as
other languages in general.

~~~
adev_
Because nobody want to program in (((( Guile )))), to the point that even GDB
disable its support as extension language.

~~~
spacesuitman2
However undesirable it appears at first, it does prevent the creation of an
infinite number of new, incompatible languages. Config languages tend toward
turing completeness and just become turing tarpits. That's why I'm asking
about using a Lisp which is extendable to its problem domain.

Source on gdb disabling it? Just writing `gr` in gdb enters the guile repl.

~~~
adev_
It has been disable by default and is not even compiled-in anymore on all
major linux distributions ( RHEL, Debian, ubuntu ).

>(gdb) gr Guile scripting is not supported in this copy of GDB.

~~~
spacesuitman2
What's your version? I'm on 8.2

------
r32a_
I've had the displeasure of being forced to use nix and to me it seems like an
overengineered piece of garbage. I don't see why anyone should use this vs
competitors

~~~
GlennS
Why would anyone use it versus its competitors? Here's why:

1\. You can uninstall a thing and it will no longer affect your computer.

2\. Your environment will work the same way on your colleague's computer.

3\. Your environment will work the same way years down the line.

4\. Your environment will probably work the same way years down the line, even
after you've applied security updates. If it doesn't, it will probably be
clear what's broken/different.

5\. You can install many different environments on the same machine, and they
will probably all work. On the rare occasions where they don't, it will be
because they interact with system services or limited system resources, and it
will be clearly defined how that happens.

6\. All this is true across most programming languages, system services, and
all sorts of tools.

7\. You can combine this with direnv (or direnv-mode for Emacs) to make it so
that you can just cd into a directory and magically get all the dependencies.

8\. You can put the recipe for your environment in Git.

Other than Nix and Guix, I don't know of any tool where these things are true.
Docker and Virtual Machines get sort of half way, but tend to rot over time.

But yes, it's difficult to learn and in many cases the usability is poor.

Final bonus point:

9\. Nix is so good that it can even make Autotools work correctly.

~~~
r32a_
I don't care about those features, I just wanted to download the packages and
it's dependencies and in the end it never did that.

Nix is probably good for many things, but it's not simple and to me it's
trying to do too many things.

~~~
sparkie
The reason you can "download a package and its dependencies" with other
package management systems, is not because they are technically superior, but
because they've had countless man-hours of contributors making sure that their
central repository contains packages which work well together.

As soon as any assumption changes, like for example, adding a third-party
application repository, then you need to concern yourself with all of the
issues mentioned above, or you'll end up wasting your days on manually
building and installing packages locally.

The point of Nix is to do this once only. If you build and it runs, it should
do the same for everyone, regardless of what other repositories they use.
Package management becomes completely modular and does not depend on some
centralized state like a central software repository, or the state of your
machine at time of install.

Nix isn't trying to do too many things. It's actually much, much simpler than
using a bunch of semi-compatible tools which all attempt to do similar things
in ad-hoc ways. Nix is just a dependency management system where dependencies
are specified by their content hash. Your machine contains a content-
addressable store of objects which can be _precisely_ referenced by any other
object. It takes the guesswork out of dependency management. Other dependency
managers effectively run a search engine to try and find an appropriate
dependency from some search terms.

