While this post is correct, I think the ship has sailed here. If we need a post defining layers of the ecosystem and boundaries between different things with Nix in the name, then we have a problem. And the problem is not the lack of blog posts carefully defining the terminology.
If rather we started explicitly calling the language Nixlang or Somethingelse for example. Flakes are a great example of not being “Nix recipes” - we call them flakes and the boundaries are obvious.
nixlang is such an obvious and good idea, I am going to start using that convention immediately.
+1. It’s barely a rename at all, and removes the awkward overloading of “nix” (to refer to the language and the wider ecosystem).
Same here - I had been using “Nix the language” (along with “Nix the package manager”) but nixlang is so much better.
Could part of the problem be the audience? I’m not sure if the author is directing this at nix developers, such as those building hosted solutions or tooling, or the general developer the Nix community is trying to onboard. The blog site is called “Haskell for all”, so I’m torn between “Haskell” and “for all”, as there is some tension there in that title, which is probably a good thing. What the author is saying makes a lot sense and actually was helpful to me, but I care about Nix.
I mean a lot of people use Nix tools at the margins. They many not fully rely on it because they haven’t had a chance to invest time to learn nixlang. So many talk about Nix because it’s mind-blowing, but haven’t spent close to anywhere close yet to a 1000 hours using it in general. Me included. Hard for it to sink in until then. Nix is marketed to all developers. It’s mentioned on all the major places where developers tend to congregate on social media, such as Hacker News, Twitter, and Youtube. So they may not get it really because there are so many parts to Nix’s universe.
I don’t think these smart naming conventions, like calling Nix’s language nixlang or Flakes not being something like “Nix recipes”, will help the general developer, too much. They won’t be using Nix at all until it’s dead simple, like how Github made git, or Coinbase made blockchain. They may use tangentially or use it then bail and say ‘this part is hard or no good’. Nix is not even a blip on radar in absolute terms- I don’t think StackOverflow Survey even mentioned it this year. It’s kind of cool to see Nix just cross critical mass, at least from an infrastructure standpoint, where it’s going to be on the radar very soon in some way.
Any system with content-addressability and cryptographic concepts exposed to the user is inherently complex. So many moving parts. How many people does anyone know (outside of places they met on developer communities online) that are near-experts in git, ipfs, nix or the blockchain? And how many are near-experts in all 4 of those, even here? Most developers have no idea even what git is beyond basic commits and basic feature branch merging, let alone what a directed acyclic graph is. Or what a layer 2 (or 3 I can’t keep up) blockchain is, such as with Avalanche subnets.
I think this is fair. I like the idea of Nix, but I tried it a while back and wasn’t ready to take on the learning curve it presented.
While I’m somewhat aware of the layers the author describes, I don’t think the “new user” experience separates them well (or at least it didn’t in ~2019). The overall impression I came away with was “Nix is complicated”.
I see. If you have nodejs projects, checkout node2nix. Two commands and you can launch an app with nix. I develop a serious service with it, although we deploy with a docker image to the cloud. It’s so much nicer than running docker-compose up and messing with docker networks and port mapping. There are other projects, like rust2nix (haven’t tried yet). Sure others exist or are on the way. Think these types of high level projects are the future for devs like you and me. And AI-CoPilot stuff that can generate Flakes (or whatever they invent in the future) for you or get you over 60% there.
I’d say nix is complex. Not to nitpick. So one day it will be super simple for end-users, like with node2nix. The dependency hell of npm or python’s conda or pip is complicated. Complex things are made of simple coherent parts - that’s nix. I helped a friend rebuild a dependency tree for a Windows python training model for Linux in WSL. I had to install everything from scratch using conda and pip in a docker environment. My PC almost blew up from calculating the dependency graph. . Not to mention complications with docker recognizing recognizing the gpus ithat I had to research to solve.
There is a lot of unfortunate overloading/confusion around different parts of the Nix ecosystem.
On a more positive note, this problem is only getting attention due to success of reusing the modular parts of the Nix ecosystem:
Still, I’m glad to see work on improving the naming.
I don’t really know anything about Nix but I’ve always found the naming especially confusing. Is it an operating system? A Linux distro? A command line tool? But it turns out it’s… all of these?
Branding goes a long way and it’s important for all kinds of things not just for profit companies and products. I’ve worked at companies where internal tools had thought put into naming and even logos made (because it’s fun!)
But as many have expressed here, ship has sailed on that. Rust has a good example of not naming everything ‘rust’ their cargo and crates.io etc. and on the flip side I think Go did a pretty good job of keeping everything named the same but logically so.
Stop calling everything “Nix”
Stop calling everything “Nix”
Advice that probably should have been given before the Nix project proceeded to prepend “Nix” to (almost) everything.
Or, in other words, ship, meet sailed… can’t chastise demand-side users for overloading a supply-side overloaded term.
The Nix space seems ripe for better hosted tooling to:
IIRC https://hercules-ci.com/ may be (in part) what you are describing.
Also found this project https://github.com/cachix/cachix https://www.cachix.org/ when searching for Hercules CI. I wasn’t aware there were hosted binary cache services. Thought only NixOS had a cache service for user convenience. Pretty cool.
You can also run a cache on S3 (or an S3-compatible service - I run mine on Cloudflare R2), though the documentation for getting that set up and configured right is atrocious.
https://garnix.io/ does a few of these (disclaimer: I start garnix)
Seems one of the big value drivers in this and other hosted binary cache services is the real cost-savings. Running CI/CD operations on hosted providers, such as Github, isn’t necessarily free for heavy users.
Does this exist as anything beyond a Discord channel? The web page doesn’t seem to have any links to actual software, and a quick web search didn’t turn up anything related. (But there sure are a lot of unrelated projects with the same name.)
I chatted with someon on Tangram. Says they are in development and were seed funded. They’ll make the Github public in the future. He said it doesn’t work with Nix. It’s a content addressable system though. Looks interesting. Will definitely check out the docs when it comes out.
It’s a dev tools startup. I think the dev environment management stuff is still in development, which is probably why it’s just a discord chat atm
The name of the post is unfortunate as it obscures very useful content behind an unnecessarily negative headline.
I bring this up because I’d like to share a nice short summary of the outlined Nix layers with less Nix-savvy colleagues, but I have to preface any recommendation with “don’t worry it’s actually really good!”, as opposed to something positive along the lines of “A short introduction to the layers of Nix”, or similar.
It’s a good article, thanks for writing it! Just some minor feedback for next time.