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 <co...@wiresong.com> writes: > On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner <cam.t...@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@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev