51–60 of 69 posts
I don't understand why any languages exist for describing packages, its a layer above describing real dependencies like with make, ninja, etc. Just have an os written in something like premake but with a nicer DSL.
Does anyone know the rationale for creating Nixlang? Guix's use of Scheme proves there isn't a novel feature unavailable elsewhere, so it seems like a lot of wasted effort to implement a language that will likely only ever be used for one suite of programs. (And tooling; though almost none exists now, making the choice even more expensive.) I've tried to find one, but "nix" is a difficult thing to google for given th…
Nobody wants an arbitrary complex program for describing some trivial build steps. A programming language here is an anti-feature. Ideal would be some DSL that isn't even Turing complete, but that's not practical at the moment. Maybe we'll get there some day.
Earlier quoted context omitted.
Probably the same reason why Guile or Scheme didn't get as wide-spread as other languages in general.
Because nobody want to program in (((( Guile )))), to the point that even GDB disable its support as extension language.
Source on gdb disabling it? Just writing `gr` in gdb enters the guile repl.
Does anyone know the rationale for creating Nixlang? Guix's use of Scheme proves there isn't a novel feature unavailable elsewhere, so it seems like a lot of wasted effort to implement a language that will likely only ever be used for one suite of programs. (And tooling; though almost none exists now, making the choice even more expensive.) I've tried to find one, but "nix" is a difficult thing to google for given th…
I like Scheme, but I think a lot of people actually wouldn’t want to write their packages and OS configuration files as S-expressions. Nix is an extremely simple language with quite familiar syntax, a kind of JSON with functions and string interpolation. Note also that Guix uses Scheme a lot more deeply than Nix uses the Nix language, in the sense that Nix uses e.g. shell scripts where Guix uses Scheme statements. Ac…
I really like nix the package manager and like NixOS the distribution, but learning nix the language was an awful lot of work, and I'm not convinced that it couldn't have been accomplished with a language that is more familiar (Guix demonstrates that baked-in lazy evaluation is not necessary). Even tiny things like "sets" as a name for an associative data type make it just that much harder to learn.
Earlier quoted context omitted.
But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point. Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. Maybe it is because I have written a fair bit of Haskell before. (Of course, I understand the argument that it would have been more comfortable…
> Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. I mean... It's not a "real" language in the sense that there exists any tooling, debuggers, unit-test suites or anything. You write your recipes and try to see if they work. And when they don't you have no idea why. With a real programming language (like Scheme) I could evaluate somethin…
A few correction on the otherwise good article: * Nix 2.0 includes the repl. Just run `nix repl` * The URL literal returns a string * It would be good to explain how the ` ` notation resolves paths from the NIX_PATH. For example ` ` looks for the `nixpkgs` key in `NIX_PATH=nixpkgs=/path/to/channel`
Earlier quoted context omitted.
I like Scheme, but I think a lot of people actually wouldn’t want to write their packages and OS configuration files as S-expressions. Nix is an extremely simple language with quite familiar syntax, a kind of JSON with functions and string interpolation. Note also that Guix uses Scheme a lot more deeply than Nix uses the Nix language, in the sense that Nix uses e.g. shell scripts where Guix uses Scheme statements. Ac…
"familiar syntax"? Perhaps if you use Haskell or ML. That's probably a tie with s-expressions for popular syntax, but definitely not familiar to most people. I really like nix the package manager and like NixOS the distribution, but learning nix the language was an awful lot of work, and I'm not convinced that it couldn't have been accomplished with a language that is more familiar (Guix demonstrates that baked-in la…
Earlier quoted context omitted.
"familiar syntax"? Perhaps if you use Haskell or ML. That's probably a tie with s-expressions for popular syntax, but definitely not familiar to most people. I really like nix the package manager and like NixOS the distribution, but learning nix the language was an awful lot of work, and I'm not convinced that it couldn't have been accomplished with a language that is more familiar (Guix demonstrates that baked-in la…
I haven't used nix, but this primer seems pretty straightforward. Was the learning curve you faced perhaps due to missing or hard-to-find documentation at the time, or something else?
Does anyone know the rationale for creating Nixlang? Guix's use of Scheme proves there isn't a novel feature unavailable elsewhere, so it seems like a lot of wasted effort to implement a language that will likely only ever be used for one suite of programs. (And tooling; though almost none exists now, making the choice even more expensive.) I've tried to find one, but "nix" is a difficult thing to google for given th…
Other pain points:
- the NixOS learning curve is steep. There are two many tools with too many obscure options with sometimes overlapping features.
- small group of maintainers with no real documented security process...just an assurance that they path as quickly as possible
- many packages are old if they're not mainstream
I would love to see the concept of Nix reimplemented in a non-niche language without the fsf zealotry... I'd switch my company to something like this in a heartbeat. I think there's a real business opportunity for someone willing to take that on.