Here we want to reuse some variables to not duplicate then for various “states”. YAML doesn’t allow such variables, you have to use template language Jinja. While it look simple, it is still a language which you have to learn. Otherwise you’ll have troubles when you try to do something more complicated then variable extract.
For example, you’d like to extend example above and test new version of SFTPPlus. How would you override version args? While it is possible in YAML+Jinja, it is of same level of complexity as Nix solution would be.
Main feature of Nix is that it doesn’t require Jinja template language, it is template language already. Those who create new services, not just use others work, appreciate such a feature.
After Eelco proposal implemented, this will look like:
(or TOML or anything else common and easy to use?)
I agree with others that nix-lang being a programming language rather
than just a data description language is important.
My own contribution to the bikeshed would be that I find YAML very
opaque and difficult to write or generate. I much prefer JSON or
s-expressions (nix-lang can read and write the former, and the latter is
used by Guix).
It hasn’t been said explicitly but the thing that differentiates nix from other configuration languages is that you can define functions which are fundamental to abstraction.
a notation for nested list (tree-structured) data, invented for and popularized by the programming language Lisp, which uses them for source code as well as data.
@tinix If you want to describe complex systems without a lot of repetition, you need a support for abstractions (functions). Using the same representation for data and code (homoiconicity) is orthogonal to this.
It might be helpful to list specific examples of discomfort. Maybe there are ways to improve the language ergonomics without trying a whole new interface.
You might be able to build an interface using TOML along with builtins.fromTOML.
Without nixthe language I feel that nix would struggle with all the issues that other configuration languages suffer from. Take meta.yaml for building conda packages, ansible configuration files, and teraform configuration files. They all have ad-hoc methods for abstraction and you end up with something that is not quite json, yaml, toml, etc. I agree with the steep learning curve and hopefully we can do something to address this.
Maybe there exists a subset of derivations that can be expressed only with pure data. In that case it would be possible to write a mkDataDerivation that takes the data in. Then if there are more advanced use-cases it’s always possible to extend and override.
Not thinking too deeply about this:
name = foo
version = 1.0.0
[source]
type = git
url = https://github.com/foo/bar.git
rev = v1.0.0
[meta]
license = mit
homepage = https://github.com/foo/bar
description = "the traditional bar package"
Already here I want to be able to inject the version in the rev
This would be a counter to the natural progression from YAML to YAML+templating. Instead, load the YAML (or TOML) and then extend it programmatically.
I don’t like the idea of loading YAML/TOML and then extending it: it will make things somewhat easier in some simple cases, and considerably more complex in non-trivial cases. Now, instead of learning and understanding Nix, one would need to also learn and understand TOML, how it’s translated into Nix, and how to extend the translations. Not good at all.
I’m slowly becoming more and more of a fan of Nix, despite my general dislike of dynamically typed languages and my relative inexperience with functional languages.
I’ve spent years in the trenches with Kubernetes, wading through pools and pools of YAML interspersed with bash and salt and jinja2 templating, and have watched various startups try a myriad of things to improve upon the pain of managing/composing so much “YAML”. I’m pretty solidly convinced that Nix’s approach as a configuration DSL, or Pulumi’s usage of Turing-complete runtimes that can emit config, seem much more reasonable at as soon as any level of abstraction or parameterization is introduced (which there’s plenty of in nixpkgs). Not to be extreme, but trying to imagine nixpkgs as primarily-expressed in yaml is already giving me a headache. In my mind, Nix and YAML are categorically different.
I’d originally liked the idea of having data-driven packages, for some probably large subset of “really normal” and easy-to-build packages, but I think I’d want to see more examples of what it would look like to override (parts of) those package definitions. Since they are just “plain ole objects”, they could still be pure-data Nix files – not as recognizable as JSON/TOML/YAML maybe, but probably still relatively easy to quickly grok, right? Then, when the package inevitably becomes “less” complex, it’s a smaller diff to start adding in the more complicated bits with more Nix syntax.
And since someone else mentioned Terraform, I feel even more conflicted with Terraform and HCL. It’s better than nothing, but I’ve NEVER seen it used on it’s own. Always with a bunch of extra templating/generation/sed-shell-scripts/etc. It also seemed sort of poorly (loosely?) implemented until this most recent “hcl2” rewrite that seems more consistent. I don’t feel similarly constrained or the need to “hack at things” as much when using Nix. Or it feels better supported? Not sure.
As for YAML specifically (as opposed to TOML maybe) it has plenty of its own usability warts. Lots of nearly useless parsers when it comes to error messages, easy to get tripped up on whitespace or semantic oddities around special values that are misinterpreted, etc.
Nix is the worst configuration language ever invented, except for all the others. (Especially YAML.)
If we’re going to support another, simpler configuration language, I think it should be Dhall. It can’t replace Nix entirely, but it can handle lots of NixOS configuration scenarios, just for starters.
Amazing how kindly this post was received. Try going to any other programming community and saying “hey, why do you use this language that sucks for no reason, and not thing that has far fewer features instead?” and see the reactions you get.
Amazing how kindly this post was received. Try going to any other programming community and saying “hey, why do you use this language that sucks for no reason, and not thing that has far fewer features instead?” and see the reactions you get.
And this is why I am happy to be contributing to nixpkgs.
A lot of this can be solved by having the nixos cli tools be able to interact with the system’s configuration file. Right now all that configuration has to be done by directly editing the configuration.nix. The next step for usability is to enable admins to make changed with a cli tool “nixos whatever” and have those changes be reflected in the configuration.nix. A good examble of this would be “nixos install firefox” where firefox gets installed and added to the configuration.nix.
There are many causes why function invocations with the same parameters yield different results, such as functions returning time-stamps, generating random numbers, performing I/O, accessing global variables. These causes are called side-effects in the functional programming community.
Because C (and many other commonly used programming languages) allow these side-effects to be programmed, they lack referential transparency , meaning that functions cannot be replaced by its value without changing the behaviour of a program.
which apparently has functions and …
‘Most jq builtins are referentially transparent, and yield constant and repeatable value streams when applied to constant inputs. This is not true of I/O builtins.’ - Redirecting to jqlang.github.io
jq wasn’t designed as language from beginning. It is simple when query is simple, but you quickly dive into quirks when your query is out of original jq scope. Nerveless, it’s a nice tool and I made a Nix equivalent some time ago, nixq (nixq - jq but with Nix syntax · GitHub). To be fair, my approach isn’t performant at all (it chokes on large inputs).
