3 ms·
It's really not that complicated if you know functional languages. If anything it's quite minimal. It just looks a bit weird because it uses semicolons unlike m
by chpatrick 3y ago
It's really not that complicated if you know functional languages. If anything it's quite minimal. It just looks a bit weird because it uses semicolons unlike most functional languages. I kind of wish they just kept JSON/Python syntax for attribute sets and lists.
What's complicated (and often not or only lightly documented) is nixpkgs, the package library.
- 0x6c6f6c 3y agoTo that effect, https://mynixos.com https://mynixos.com has been a really awesome resource for docs. But yeah, the Nix language is definitely not the complicated part. You can get the language down in a day or two with their reference doc. What is difficult is understanding the patterns to NixOS and nixpkg's. Overlays, derivations, packages, flakes.. that's where things get the most confusing. It's a huge step away from other packaging mechanisms like PKGBUILDs but much more powerful and type-safe. But some things just aren't thought of, like home-managers `home.sessionPath` for updating the PATH is _append-only_.. so it literally cannot be used to prepend a preferred bin path. So you follow the typical convention as you might already and include it in the shells rc with `export PATH=/custom/path/bin:$PATH`. Which is the exact kind of safety you'd have today, so it's not worse, it's just another one of the shortcoming of the modules, as opposed to the Nic language itself. The same shortcoming would exist if you used HCL to declaratively define additional PATH paths. It's typically the module design, not the language.