[Nix-dev] NiJS package manager

Tue Apr 1 23:52:37 CEST 2014

Hello everbody,

It seems that my blog post caused quite a bit of discussion, which I really appreciate! 

I have decided to update my blog post with some additional notes based on the discussion:

http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
________________________________________
From: nix-dev-bounces at lists.science.uu.nl [nix-dev-bounces at lists.science.uu.nl] on behalf of Gergely Risko [gergely at risko.hu]
Sent: Tuesday, April 01, 2014 9:19 PM
To: nix-dev at lists.science.uu.nl
Subject: Re: [Nix-dev] NiJS package manager

Guys,

Wasn't this "replace Nix with JavaScript in a community of folks who
love purity, lazyness and high-level languages" post an April's fools?
Check the date!

Or am I mistaken and is this a serious proposal?

Confused,
Gergely

On Tue, 1 Apr 2014 10:43:15 -0500, Colin Putney <colin at wiresong.com> writes:

> 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
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
nix-dev at lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev