Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Google zx is a good example of this done right, as is Pulumi.
Kris Nóva said it best: "All config drifts towards Turing completion."
Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Google zx is a good example of this done right, as is Pulumi.
Kris Nóva said it best: "All config drifts towards Turing completion."
Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living on NixOS for ~3 years now, with 4 active Nix deploys in my house.. i just don't like the language.
I wanted to use Nickel, but it turns out that it can't do everything you'd need it to do to completely replace NixLang. So right now I'm bikeshedding on what to use instead (and desperately trying not to invent something), in other words it's definitely being renamed. Either way there's a bash script in the `test` dir that shows the general concept.
A .nix file is either a config file itself or a function that returns a config file or a function. By passing in enough parameters, you get the configuration. I've not seen as clean a way of doing this anywhere else. Guix uses Guile which is a full programming language and can probably have side effects. They use something called G-Expressions which is not quite clear to me.
Ie yea, i can load up the Eval and call my config func - but what about the params? Well now i have to generate the params. Some of them might be easy, but some are difficult as hell - and if they differ now executing my func in the Eval is not producing the same output (or failing entirely) as it does when i run it "for real".
Nix in practice felt like all of the problems of imperative languages but wrapped in a nice functional wrapper. It was functional without any of the real benefits of functional - to me.
Eg i can't easily get the same input and pass it into a function to produce the same output. To be able to view a function as a simple slice of functionality that i can inspect, debug, etc. They have get access to the entire universe (nixpkgs/etc), a huge stdlib, etc - and you need to recreate all of that if you want to use the function.
Notably error reporting is atrocious, but an interactive debugger would be amazing too. Ie to set a breakpoint and hop into an eval at your breakpoint. Would help immensely.
Still i just can't get behind a dynamic typing for anything remotely complex.. which i would describe Nix as. I have been counting down the days for Nickel.. it's been a long wait.
FWIW, I have flirted with my own DSL implementations in a few cases. Certainly, language design is much more complex, but I also felt that once you understand enough of EBNF/parser generators (and some of the simpler alternatives), this is a very powerful option as well.
[1] https://twitter.com/funcOfJoe/status/1319667607214067712
If we take it one step further though and think about portability of configuration, I think that is one of the reasons we end up with operators.
build: src/build.py
test: src/test.pyPulumi was also a good tool when I was doing kubernetes deployments.