[Nix-dev] NiJS package manager

Colin Putney colin at wiresong.com
Tue Apr 1 17:43:15 CEST 2014


On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner <cam.turn at gmail.com> wrote:

> >
> http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
>
> > I have discovered that the Nix expression language is complicated and
> > difficult to learn. Like Haskell, it has a solid theoretical foundation
> > and powerful features (such as laziness), but it's too hard to learn by
> > developers without an academic background.
>
> I entirely disagree with this. From my perspective, Nix is a great
> language which covers the simple cases simply.


Me too.

Ditching Nix would be a disaster for the NixOS ecosystem. Here's why:

1) It's a lot of work. The NixOS has some momentum, and a decision to
deprecate Nix and rewrite everything in NiJS would stall that momentum.
Lots of effort would go into reimplementing stuff that already works fine,
and dealing with interoperability problems between legacy Nix expressions
and newly-written NiJS code. During the transition period, it would create
confusion for newbies and cause the whole system to be more difficult to
understand, even for experts.

2) The main barrier to adoption isn't Nix syntax anyway. It's inertia.
NixOs is fighting over 40 years of tradition in the Unix community. There
have been pitched battles about whether /usr should be mounted read-only,
whether 3rd-party software should go in /usr/local or /opt/local, and
whether binaries run by other processes should be in /usr/bin or
/usr/libexec. For people steeped in the details of the Linux Filesystem
Hierarchy Standard, something like the nix store is completely alien. Every
time Nix comes up in a public forum (Reddit, Hacker News, mailing lists)
there's a hundred comments that boil down to "you don't understand how
packaging works." For every person who's thrilled by the idea of a
purely-functional package manager, there's a thousand who think apt-get is
"so easy!" and can't even imagine that something better is possible.
Switching to Javascript as the packaging language won't solve any of those
problems.

3) Asynchronous programming is hard. Sure, there are a lot of Javascript
programmers out there, who will have some experience with callbacks. For
everybody else, callbacks are a pain in the ass. They make it hard to
reason about flow control, which makes everything else harder, especially
error handling and debugging. Javascript may be more mainstream than Nix,
but for a lot of people, it won't be easier to learn.

4) Switching to node may attract Javascript programmers, but it will repel
people in other communities. If Nix comes to be seen as a "Node thing" it
will cause people to ignore it just because they're using some other
language. It might even cause people to start making clones for their
languages--think Rubix and PyNix--so they integrate better with their
ecosystem. (See, for example, Make, Rake, Grunt and Fabric.) Because it's a
domain-specific language, Nix expressions don't have to come down on one
side or the other in the language wars and can play nicely with everybody.

5) Switching from Nix to NiSJ goes against trend. Node is popular, sure,
but it doesn't completely dominate programming the way Java did in the 90s,
and it never will. There's probably still some growth left in the Node
ecosystem, but not orders of magnitude more. On the other hand, functional
languages have their best years ahead of them. Clojure, Erlang, Scala and
Haskell are all growing steadily, and functional languages are seen as the
future, even if they're not dominant today. The cool kids have switched
from Ruby to Node in the last few years, but it won't be too many years
before they switch to something else, and it's likely to be a functional
language.

6) As languages go, Nix is actually quite practical and approachable.
There's no compile step, and no type system to form initial barriers to
entry. Nix files tend to be short and consist mostly of attribute sets,
which have a very obvious syntax. It's easy to copy-and-modify a nix
expression if you only need to make minor tweaks. This is exactly the kind
of approachability and simple-to-get-started feel that made PHP so popular,
but Nix has much more elegant underpinnings.

So please, keep the faith! Nix is solid. There's no need to switch to
something else.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140401/72f1055a/attachment.html 


More information about the nix-dev mailing list