Comment by tomn
3 days ago
> the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for)
None of these are language problems, they are problems with the way nixpkgs is structured and the ways nix is used (or your understanding of those).
Perhaps being purely functional causes some of this complexity/unfamiliarity, but in that case replacing it with another pure functional language (the original point i was replying to) is not going to help. Maybe replacing it with scheme (functional/imperative) does, I don't know.
The semantics of the language make it virtually impossible to write a good lsp with “go to definition”, particularly when you get into the module system (which is where you need it most). This is a massive barrier to entry and the only way to solve it is to spend a lot of time imbibing nix lore. It’s a fundamentally unsustainable language design for adoption as an incidental build tool and it’s no surprise that those who manage to persist are also the ones who spend a lot of time with it. Unlike a more ergonomic language with good tooling and semantics which encourage adoption by casual users.