Hey @bme,
Having had a little more time to think about it, I feel my first reply answered the roadmap part, but not your deeper concern.
I hear the worry about producing people who can run nix shell nixpkgs#... recipes without understanding what Nix is doing, and I agree that would be a bad outcome. Cookbook-only Nix education creates fragile users: they can copy commands, but they cannot diagnose evaluation, understand nixpkgs as a package set, reason about imports/fetching/pinning, or explain why flakes are shaped the way they are.
The tradeoff I’m making in First Contact is that it is aimed at a true first-time Nix user in their first session, not someone already ready to start from the REPL and work toward derivations. The goal of this first Part is deliberately narrower: install Nix in a disposable VM, inspect what changed, get one useful result, see dependency declaration once, remove it cleanly, and leave with enough mental model to choose the next route.
That said, your feedback is useful because if First Contact reads as “Nix equals modern CLI incantations,” then the boundary is not clear enough. The intended shape is:
- First Contact: early payoff, install footprint, store/profile/daemon basics, temporary environments, package discovery, dependency-declared scripts, uninstall. It is mostly a means to answer “Why do I care about
nix?” by showcasing some of the things other package managers fail to do.
- Foundations after that: store paths, closures, expressions, attribute sets/imports, functions/laziness, fetching and pinning, nixpkgs as a package set, derivations, builders/stdenv, and error diagnosis.
- Flakes only after the problems they address are visible.
On the installer choice: I went with the Determinate installer here because its planned install and receipt-backed uninstall are good for the install → inspect → uninstall lesson. It gives the lab a predictable footprint that learners can audit on the way in and on the way out. That is not meant to hide the upstream status of nix-command/flakes, or to imply that the Determinate defaults are the only canonical way to learn Nix. The course should say that distinction plainly and I was hoping the call-outs in the prose would help with that.
So I do not think First Contact should become “REPL and derivations first.” I do think I need to tighten the presentation so a learner understands that the CLI work is the first handle on the system, not the system itself.
On the tab close/reopen issue: that is just a platform bug, and I need to reproduce and fix it. If you are willing, I would appreciate a few details:
- browser/OS;
- which chapter you were in;
- whether the VM had been idle for a while before closing the tab;
- roughly how long the tab was closed;
- what the wake button did when you clicked it.
No pressure, but I would also value a short follow-up conversation at some point, not as a “please bless the course” thing, but specifically to stress-test the curriculum shape: where First Contact is a useful beginner handle, and where it risks giving people surface fluency without the model underneath.
P.S.: My apologies for posting multiple responses. I’m still trying to get the hang of the UI here. 