I have a very hard time getting behind these complex configuration languages. To me what makes a configuration format good is the simplicity of <i>reading</i> the configuration of a program, and almost all of these languages are optimizing for feature complexity over readability. I think that all of the popular config formats (yaml, json, toml, etc) have issues, but none of the major issues with them have to do with being unable to represent a fibonacci sequence in their language.<p>To draw a direct comparison, when I look at the examples in the github repository, all I can think is "I would never want to have this be a source of truth in my codebase". While I get frustrated w/ whitespace in yaml and the difficulty of reading complex json configuration, if I need a way to programmatically load complex data I would almost always rather use those two as a base and write a 'config-loader' in the language that I am <i></i>already<i></i> using for my project (instead of introducing another syntax into the mix)
Documentation is terribly lacking, but in addition examples are perplexing.<p>Where is the "Url" type, which should be a union of a constrained subset of "Str" (as built by mylib.makeURL) and a three component record (as used in the example)?<p>Where can I specify that the "urls" list in the configuration must be present and nonempty, and that "host" and "port" are mandatory (or not)? And that the type of "urls" is a list of "Url", the type of "port" is "port", etc.?<p>How can a general purpose port <i>type</i> have a meaningful default value, given that duplicates are generally fatal and a configuration can contain multiple ports? Only individual port usages (e.g. ftpPort and telnetPort in a commonNetworkServices record) should have defaults.<p>Where is the body of numToStr? Maybe in some unmentioned standard library?<p>Is there some kind of enforceable separation between the configuration file (untrusted and supplied by the user) and a schema it must satisfy (trusted and supplied by the application)? What forbids the configuration file to, say, redefine makeURL as Str -> Str -> Num -> Str -> Str -> Str (to add a HTTP path and query string) and make the application's URL parsing fail?
I have been in a deep rabbithole with Nix lately. It seems almost too good to be true. Declarative configuration, and with NixOps, declarative provisioning as well. Along with the other tools in the ecosystem, there is quite some overlap with some of the popular tools from Hashicorps and others. I am just beginning to learn the intricacies of DevOps, and Nix seems like a one-stop shop. What are the downsides of Nix?
I love using cap'n'proto to store configurations. It's really slick.<p>+ Type safe since you define the schema for every part of your configuration.<p>+ Ridiculously easy to read/understand (writing has a small ramp curve to build the muscle memory).<p>+ Type system is very flexible & rich (lists, maps, unions), supports generics (for built-in & custom types) & everything is neatly composable (including constants that reference constants).<p>+ The config compiles down to a minimal binary file.<p>+ You can have arbitrary configurations in 1 file (you compile a specific constant to a file so each configuration you want is just 1 constant value you define in the schema).<p>+ The binary file can be converted back to text using standard cap'n'proto tools so it's easy to double-check the config you're deploying.<p>+ Perfect backward/forward support for the configuration as long as you follow the rules (similar to protobuf/flatbuffers) since you have to define the schema for your constants.<p>+ Loading the config file from any data source (disk, network) is trivial and for on-disk usages you could mmap the struct to get even better performance (only the parts of the config you access would get paged in).<p>+ Supports a variety of languages. While the RPC stuff has a bit less adoption, the parts needed for configuration should be available in the most popular languages (I think the only missing language generator is Swift).<p>The only negatives are:<p>- You do have to define the schema for your config<p>- There's a single upfront cost to integrate cap'n'proto into your build system if you're not using CMake.<p>Neither feel like prohibitive negatives though. If you're looking at strong typing, why not go all the way & make sure that your entire config has a strongly typed structure to it? Not just that some field is an int also that there's certain specifically named fields & that accessing these fields in a strongly-typed languages will result in build errors if you forgot to change something.
There is definitely a need for this class of tools (statically typed expression-based config languages), but it’s super weird to praise Nix as very simple and easy to understand and then to gripe that Dhall is complex.<p>I’ve been trying to learn Nix on and off for years and the language is often one of the things that trips me up. Dhall on the other hand looks simple even though it insists on a Haskell-esque syntax (which I find to be difficult to read).<p>All I really want is Starlark with type annotations or something similar, but Dhall is pretty close.
What is the selling point for this vs say Dhall, which looks superficially similar (Haskell-ey config lang)?<p>The examples for Nickel currently look a lot more like programming than config. Why not just use a general purpose programming language that you already know and has many libraries and mature tooling?<p>Dhall advertises a lack of Turing-completeness as a feature. One of the Nickel examples shows an implementation of fibonacci function... (I have no idea if this implies Nickel is TC, nor why I would need such power in my config)<p>> Dhall features a powerful type system that is able to type a wide range of idioms. But it is complex, requiring some experience to become fluent in.<p>> Gradual types also lets us keep the type system simple: even in statically typed code if you want to write a component that the type checker doesn’t know how to verify, you don’t have to type-check that part.<p>> Complementary to the static type system, Nickel offers contracts. Contracts offer precise and accurate dynamic type error reporting, even in the presence of function types.<p>It's not clear to me that gradual typing as a mix of statically typed code + untyped code with "contracts" is necessarily simpler than just one or the other.<p>It's not clear to me that a specialised config language combining code + schemas is necessarily better than an existing general purpose language + some language-agnostic schema DSL.<p>I don't know, maybe this is all great, I feel the benefits need to be more clearly explained and demonstrated though.
I see so many complain about these config languages. I think it is a bit black and white to think of a perfect separation between code and config. In a perfect world and easy situations yes. But I think you are all missing the point of these languages. In my eyes they are templating languages. Have any of you guys seen the Helm charts some of us have to write daily? Mustache coding is terrible! I would love any of these languages instead of that. The only thing worse would be to have to write all the yaml yourself every time instead of any templating at all.<p>To that end, you could use any programming language to generate the yaml for your config. But then some of these has some nice features. I really like that Dhall is only a total lang and it does some nice things with importing dhall files.<p>That is not to say you should unnecessarily complicate your config. Keep it easy and separate from code as much as possible.
Timely, we are talking about TC in the Cue slack today. Nickel calls out its Cue inspiration while maintaining TC.<p><a href="https://github.com/tweag/nickel#related-projects-and-inspirations" rel="nofollow">https://github.com/tweag/nickel#related-projects-and-inspira...</a><p><a href="https://cuelang.org/community" rel="nofollow">https://cuelang.org/community</a>
> All in all, the Nix language is a lazy JSON with functions.<p>That's news to me!<p>I have been slowly learning the language, only enough to configure and package stuff as needed for my personal use, but it has not just been a lazy JSON with functions...
I don't want to interpret my configuration. I don't want it to act as a source code.<p>Many places at Google use text representation of protobuffers as config files and I like it a lot. It's typed. It's readable. The schema and text are source controlled. You have code generators for many languages.<p>(Work at Google, opinion is mine)