6 ms·

I don't understand why these config systems can't be less 'programmy' (less technical). All of these (Nix/Guix/NginX Lua, etc) config systems are all so comple

I don't understand why these config systems can't be less 'programmy' (less technical). All of these (Nix/Guix/NginX Lua, etc) config systems are all so complex with layers of interesting syntax and punctuation. Why can't these use simpler (INI/YAML/TOML/CSON or even JSON) configuration schemes? It would reduce barrier to entry - simplify parsing and automation, and a whole lot of other things. Why do I need to learn yet another language just to configure and manage my system?

kodablah 8y ago
> Why can't these use simpler [...] configuration schemes? Because you inevitably need something less simple at some point. It's a hard balance to strike. Want only a config format? Get angry advanced users. Want only a programming language? Get angry beginners. Want both? Get a hodge-podge of half-and-half configs calling out to built extensions and in general a bunch of beginners finding poor code-based solutions on the internet. In general, you need a simple programming language to manage this stuff or it becomes unwieldy once it leaves hobbyist size. And mixing config formats and full-blown languages (or worse, template languages) just adds ambiguity on the best way to do something coupled with loose synchronization between the two formats, "extension hell", and half-developed code solutions with an exponential number of poorly tested combinations of exported features that beginners try to use. To see examples of all these problems, one simply has to look at the historical landscape of orchestration engines and build tools.
- edwintorok 8y ago
  Some food for thought: https://dhall-lang.org/ https://dhall-lang.org/ looks like an interesting balance between config file format and programmability. Would it be suitable for describing packages?
  - Ambrevar 8y ago
    I don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.
1ris 8y ago
Look at msbuild. It tries to use XML as a syntax for its configuration. But because you absolutely need a programming language for this task, you program a very odd language that is unlike anything else. It combines the clearty and simplicit of XML with the intuitivity of a dsl. Now think of a lisp that uses YAML as its syntax instead of sexprs. That might be a much better choice than msbuild, but do you really want that? Would that make things better?
Ambrevar 8y ago
Others gave good answers I think, so I'll just address your points directly. > [Nix is] so complex with layers of interesting syntax and puncation Precisely. Guix uses Scheme all over the place. It's just _one_ language for everything, not multiple languages. As a result, it's easier. Scheme yields very easy-to-read declarations (see https://ambrevar.xyz/guix-packaging https://ambrevar.xyz/guix-packaging for some examples), so JSON & friends don't add much here. > Parsing and automation Parsing couldn't be simpler than using the language itself! There is no need to write an interpreter here. > Why do I need to learn yet another language just to configure and manage my system? That's precisely part of my thesis: with Guix, you only need to know Lisp/Scheme (which users might already know since it's a general-purpose language). Programs going for a DSL are effectively forcing everyone to learn a language for the sole sake of using the programs.
mbrock 8y ago
I sometimes like to say that the Nix language is like JSON with functions and multiline interpolated strings, both of which happen to be extremely useful for system configuration and package definition. In fact packages in Nix are functions. Dependencies are just function arguments. It makes a lot of sense.
vindarel 8y ago
Given a point, and quite soon, you'll use advanced and peculiar yaml syntax. Want to factorize rules ? .deploy: &deploy and foo <<:*deploy etc. This doesn't simplify parsing. This is already a DSL. And the format changes slightly depending on implementations (official, gitlab,…).
vesak 8y ago
Of course they can. Check out Ansible. It's quite comparable to these systems, even if less pure and lacking some of the features.
- ethelward 8y ago
  > It's quite comparable to these systems, even if less pure and lacking some of the features. So it's not really comparable then.
chriswarbo 8y ago
Others have hinted at this, but functions are fundamental to Guix and Nix. They are "functional package managers", whose packages are written in "functional programming languages". In particular, it's rare to directly define a package; they're almost always defined using functions, which take dependencies as arguments. This allows reuse, overriding, modularity, etc. Another killer feature of these systems is their extensive libraries, which provide all sorts of functions to make packaging new stuff easier. Here's a Nix example (I'm less familiar with Guix) which defines a Haskell package, where the definition is fetched from hackage.haskell.org, automatically converted to a Nix definition (using `cabal2nix` behind the scenes), with its test suite disabled and profiling symbols compiled in: with import <nixpkgs> {}; # The Nix standard library with haskell.lib; # Haskell-specific Nix functions with haskellPackages; # Haskell packages, for use as dependencies enableLibraryProfiling (dontCheck (callHackage "vector" "0.9") {}) I'd hate to think how to define such packages if Nix didn't have the ability to write functions like `enableLibraryProfiling`, `dontCheck` and `callHackage`. None of the formats you mention (JSON, YAML, etc.) support functions, either defining them or calling them. Adding functions to such formats would be problematic in two ways: figuring out how to make them work (representations, syntax, implementation, etc.) would be a challenge in itself, especially if we don't want to break existing tools for those formats; actually using them presents another problem, since functions are used so extensively that it would be pretty much like learning a new language anyway, which defeats the main reason of going down this route. Note that Nix and Guix can offload some configuration to those more limited formats if desired, e.g. by using things like `readFile` and `fromJSON` in Nix. Personally, whenever I've done this I've inevitably wanted something more powerful, and ended up using Nix to generate the JSON; hence I don't bother these days!

kodablah 8y ago

> Why can't these use simpler [...] configuration schemes? Because you inevitably need something less simple at some point. It's a hard balance to strike. Want only a config format? Get angry advanced users. Want only a programming language? Get angry beginners. Want both? Get a hodge-podge of half-and-half configs calling out to built extensions and in general a bunch of beginners finding poor code-based solutions on the internet. In general, you need a simple programming language to manage this stuff or it becomes unwieldy once it leaves hobbyist size. And mixing config formats and full-blown languages (or worse, template languages) just adds ambiguity on the best way to do something coupled with loose synchronization between the two formats, "extension hell", and half-developed code solutions with an exponential number of poorly tested combinations of exported features that beginners try to use. To see examples of all these problems, one simply has to look at the historical landscape of orchestration engines and build tools.

edwintorok 8y ago
Some food for thought: https://dhall-lang.org/ https://dhall-lang.org/ looks like an interesting balance between config file format and programmability. Would it be suitable for describing packages?
- Ambrevar 8y ago
  I don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.

1ris 8y ago

Look at msbuild. It tries to use XML as a syntax for its configuration. But because you absolutely need a programming language for this task, you program a very odd language that is unlike anything else. It combines the clearty and simplicit of XML with the intuitivity of a dsl. Now think of a lisp that uses YAML as its syntax instead of sexprs. That might be a much better choice than msbuild, but do you really want that? Would that make things better?

Ambrevar 8y ago

Others gave good answers I think, so I'll just address your points directly. > [Nix is] so complex with layers of interesting syntax and puncation Precisely. Guix uses Scheme all over the place. It's just _one_ language for everything, not multiple languages. As a result, it's easier. Scheme yields very easy-to-read declarations (see https://ambrevar.xyz/guix-packaging https://ambrevar.xyz/guix-packaging for some examples), so JSON & friends don't add much here. > Parsing and automation Parsing couldn't be simpler than using the language itself! There is no need to write an interpreter here. > Why do I need to learn yet another language just to configure and manage my system? That's precisely part of my thesis: with Guix, you only need to know Lisp/Scheme (which users might already know since it's a general-purpose language). Programs going for a DSL are effectively forcing everyone to learn a language for the sole sake of using the programs.

mbrock 8y ago

I sometimes like to say that the Nix language is like JSON with functions and multiline interpolated strings, both of which happen to be extremely useful for system configuration and package definition. In fact packages in Nix are functions. Dependencies are just function arguments. It makes a lot of sense.

vindarel 8y ago

Given a point, and quite soon, you'll use advanced and peculiar yaml syntax. Want to factorize rules ? .deploy: &deploy and foo <<:*deploy etc. This doesn't simplify parsing. This is already a DSL. And the format changes slightly depending on implementations (official, gitlab,…).

vesak 8y ago

Of course they can. Check out Ansible. It's quite comparable to these systems, even if less pure and lacking some of the features.

ethelward 8y ago
> It's quite comparable to these systems, even if less pure and lacking some of the features. So it's not really comparable then.

chriswarbo 8y ago

Others have hinted at this, but functions are fundamental to Guix and Nix. They are "functional package managers", whose packages are written in "functional programming languages". In particular, it's rare to directly define a package; they're almost always defined using functions, which take dependencies as arguments. This allows reuse, overriding, modularity, etc. Another killer feature of these systems is their extensive libraries, which provide all sorts of functions to make packaging new stuff easier. Here's a Nix example (I'm less familiar with Guix) which defines a Haskell package, where the definition is fetched from hackage.haskell.org, automatically converted to a Nix definition (using `cabal2nix` behind the scenes), with its test suite disabled and profiling symbols compiled in: with import <nixpkgs> {}; # The Nix standard library with haskell.lib; # Haskell-specific Nix functions with haskellPackages; # Haskell packages, for use as dependencies enableLibraryProfiling (dontCheck (callHackage "vector" "0.9") {}) I'd hate to think how to define such packages if Nix didn't have the ability to write functions like `enableLibraryProfiling`, `dontCheck` and `callHackage`. None of the formats you mention (JSON, YAML, etc.) support functions, either defining them or calling them. Adding functions to such formats would be problematic in two ways: figuring out how to make them work (representations, syntax, implementation, etc.) would be a challenge in itself, especially if we don't want to break existing tools for those formats; actually using them presents another problem, since functions are used so extensively that it would be pretty much like learning a new language anyway, which defeats the main reason of going down this route. Note that Nix and Guix can offload some configuration to those more limited formats if desired, e.g. by using things like `readFile` and `fromJSON` in Nix. Personally, whenever I've done this I've inevitably wanted something more powerful, and ended up using Nix to generate the JSON; hence I don't bother these days!