My theory is that we need better learning resources (that’s why I’m working on https://mimoo.github.io/nixbyexample/), better tooling (debugging or starting a project from scratch is hard), better integration with rust/js/etc. projects based on convention (and not configuration: I shouldn’t have to point to more than a Cargo.toml or package.json and nix should do the rest)

This looks great. As someone who started learning Nix in the last few weeks this is definitely needed and will prove invaluable to future learners. I'm still completely lost on a lot of things but if I work something out that isn't covered on your site I'll try and put together a PR for it.

That’d be great!

The problem is boundless complexity. Learning resources won’t help anyone to learn and manage boundless complexity.

Are you really claiming Nix has boundless complexity?

> Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form.

Here's an opposite opinion:

> My hot take is that Nix actually has great syntax

> In particular, the way Nix handles record syntax is exemplary and more languages should copy what Nix does in this regard

And even more related to this discussion:

> A lot of the times, when people say they hate "Nix's syntax", what they more likely mean is that they hate the domain-specific languages of the Nixpkgs overlay system and/or the NixOS module system

https://mobile.twitter.com/GabriellaG439/status/156300116656...

When there are issues with debugging breakages of such environments, will a wrapper be sufficient? Does devbox have extra handling for such scenarios?

The opacity of Nix errors is largely (entirely?) constrained to the module systems (notably NixOS, Nix-Darwin, and Home Manager). (This is unfortunate, because these are actually some of the best parts of the Nix ecosystem.)

The issue is essentially that configuration options all get merged into a global namespace, but there are no facilities to track where they came from. So when configuration mismatches of certain kinds occur, you get an error in some library code that's trying to merge or coerce two incompatible values, and nothing pointing you to the two places where the conflicting values are originally set.

(This kind of error, the most common mostly-useless error message, is typically easily debugged by searching for the relevant options in your configuration and in the source code of that collection of modules. But that is still backwards and a chore, and deserves a real solution.)

Anyway, the package definitions and builds in Nixpkgs don't use any such module system in any way. So this tool is not wrapping the functionality that is associated with opaque error messages. :)

I think you're confusing Nix, nixpkgs and NixOs.

(Also Nix and Nix-flakes are two different things, like Javascript and React.)

I think this attempt at clarification is just proving xvector’s point.

It's not an attempt at clarification. It's best if you start with the problem you're trying to solve, then work backwards towards a solution.

"Nix" isn't really a thing, no more than "Linux" is. It's a collection of tools and languages and frameworks people use to solve various very different problems.

See, this is why I would like to use a wrapper.