4 ms·

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expres

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

pcthrowaway 5y ago
> Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.) Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS. On the front-end there's Svelte, which is actually compiled with Javascript, and React, which is has the biggest market share of opinionated Javascript frameworks, but at best you could say JSX is compiled to HTML. On the back-end, there's express, but that doesn't involve any compilation, and is far from opinionated...
- otabdeveloper4 5y ago
  Before Typescript there was also Coffeescript. Sic transit. :) But also things like Vue do their own compiling step too.
mikepurvis 5y ago
The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it. Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.
- otabdeveloper4 5y ago
  > The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. No, I'm talking about things like classes, abstract data types, modules, type checking and docstrings. "Programming in the large". Nixpkgs and NixOS does its own hand-rolled versions of these for each subproject. Eventually (a long time from now in a galaxy far away) we'll have some sort of standard Nix++ language and standard library.
  - mikepurvis 5y ago
    Okay, yes, I agree with all of that. Flakes are kind of a module system, but having clearer semantics around functions and classes would definitely help with both code readability and producing better stack traces. And a proper type system would be awesome. Regarding docs, it is interesting that portions of the nixpkgs source do seem to have docblock-like comments above the functions, but AFAICT there's no formalized process for extracting or rendering those. Given that https://github.com/nix-community/rnix-parser https://github.com/nix-community/rnix-parser exists, I wonder how big of a leap it would be to actually extract those, render them into rST pages, and generate a searchable Sphinx manual.
avakand 5y ago
https://github.com/divnix/devos https://github.com/divnix/devos is something close to a framework. I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.
- emptysongglass 5y ago
  I just got a spare mini-PC up on DevOS over the weekend! It's currently looking for maintainers but it's cutting edge (think hlissner's NixOS config but more generic) and gives you a huge amount of flexibility out of the box. Highly recommended if you want a Flake-based NixOS system, local or remote but don't know where to start or you'd like an example of best practices to build off of.

pcthrowaway 5y ago

> Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.) Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS. On the front-end there's Svelte, which is actually compiled with Javascript, and React, which is has the biggest market share of opinionated Javascript frameworks, but at best you could say JSX is compiled to HTML. On the back-end, there's express, but that doesn't involve any compilation, and is far from opinionated...

otabdeveloper4 5y ago
Before Typescript there was also Coffeescript. Sic transit. :) But also things like Vue do their own compiling step too.

mikepurvis 5y ago

The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it. Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.

otabdeveloper4 5y ago
> The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. No, I'm talking about things like classes, abstract data types, modules, type checking and docstrings. "Programming in the large". Nixpkgs and NixOS does its own hand-rolled versions of these for each subproject. Eventually (a long time from now in a galaxy far away) we'll have some sort of standard Nix++ language and standard library.
- mikepurvis 5y ago
  Okay, yes, I agree with all of that. Flakes are kind of a module system, but having clearer semantics around functions and classes would definitely help with both code readability and producing better stack traces. And a proper type system would be awesome. Regarding docs, it is interesting that portions of the nixpkgs source do seem to have docblock-like comments above the functions, but AFAICT there's no formalized process for extracting or rendering those. Given that https://github.com/nix-community/rnix-parser https://github.com/nix-community/rnix-parser exists, I wonder how big of a leap it would be to actually extract those, render them into rST pages, and generate a searchable Sphinx manual.

avakand 5y ago

https://github.com/divnix/devos https://github.com/divnix/devos is something close to a framework. I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.

emptysongglass 5y ago
I just got a spare mini-PC up on DevOS over the weekend! It's currently looking for maintainers but it's cutting edge (think hlissner's NixOS config but more generic) and gives you a huge amount of flexibility out of the box. Highly recommended if you want a Flake-based NixOS system, local or remote but don't know where to start or you'd like an example of best practices to build off of.