I will say, there is one element of Nix's core design that makes almost all of these integrations considerably worse than they have to be, and that's the whole IFD fiasco— if it were possible to ingest an ecosystem-specific lockfile, run a build on it, and evaluate that result, then a lot of the drama and workarounds would melt away. This is sort of supported today, but it's basically banned from nixpkgs because of how the current implementation pauses evaluation any time it needs to run a build that evaluation is dependent upon... and it can only run one such blocking build at a time.

The new rust implementation (tvix) is addressing this as one of its core design goals, allowing evaluation and builds to run in parallel. But even once it's complete and usable, it's unclear what the relationship will be between tvix and Eelco's Nix.

That's honestly not the worst thing involved.

Another is that Nix as language is yet another of those "functional programming sounds fun, let's do bare minimal pure language and forget about all the niceties that proper ones figured out".

I think my argument is that most of those issues are relatively shallow— they're problems that could be addressed with tweaks to the syntax or additions to the standard library.

The IFD issue is fundamental. It's why poetry2nix has to be implemented entirely in Nix code in order to run at evaluation time without blocking, whereas in a world where eval and build could properly interleave, this would never be done— the core logic of poetry2nix would be implemented in something sane.