by ff_ on 7/4/19, 3:30 PM with 177 comments
by jrudolph on 7/5/19, 5:28 AM
Dhall elegantly solves a major challenge: configuration management at scale. We build a multi-cloud management platform, which serves DevOps teams, IT Governance, Controlling and IT Management in large enterprises. That means we're an integration solution for a lot of things, so we need to be highly configurable. Because we also manage private clouds (a la OpenStack, Cloud Foundry, OpenShift etc.), we often run on-premises and operate our software as a managed service. Using dhall allows us to _compile and type check_ all our configuration for all our customers before rolling things out. We use dhall to compile everything from terraform/ansible, kubernetes templates, spring config, to concourse ci pipelines and customer-specific reference data to load into our product. Since adopting dhall earlier this year, we measurably reduced our deployment defect rate and re-gained the ability to safely refactor configuration.
It takes a little time to get used to, but we appreciate that it's highly opinionated around formatting and "how to do things" - somewhat in the same way as golang is. It has certainly helped that we had a member with haskell experience on the team, as dhall is built in haskell and the syntax feels familiar.
Plug: if you're looking for a job working with dhall, reach out :-)
- 0: https://meshcloud.io - 1: https://github.com/Meshcloud/ejs-compiler
by oalessandr on 7/4/19, 8:55 PM
There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes .
The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear)
I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.
by dang on 7/4/19, 6:19 PM
by hjk05 on 7/5/19, 6:44 AM
by cryptonector on 7/4/19, 7:48 PM
Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for configuration. Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means that I can use JSON, TOML-style, and other ways of expressing complex data, including combinations of them, all with "interpolation" (not quite) and complex computation being available.
[0] https://stedolan.github.io/jq/by nikolay on 7/4/19, 5:54 PM
- Why use '=' instead of ':' for attributes? If you used ':', then '=' could be variable assignment and eliminate the need for 'let'.
- Why is there a need for commas?
- Why quote via ticks?! Gee!
- What's with the '{-' and '-}' for comments?! It's like its author decided to differ at any price!
In general, good ideas, but it's too weird and unnecessarily deviates from common syntax.
by zeliard on 7/4/19, 7:30 PM
- Jsonnet (https://jsonnet.org/) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL)
- Cue (https://github.com/cuelang/cue) - a more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification.
Great thread comparing them against each other by the authors of both: https://github.com/cuelang/cue/issues/33
Cue seems kind of similar to Dhall on first sight, but I haven't used either enough for an informed opinion yet.
by andybak on 7/4/19, 6:03 PM
I hate commas at the start of lines and I would prefer not to have curly braces in a human editable/readable format.
Neither reason is terribly rational but my first impressions weren't great.
by tobr on 7/4/19, 6:07 PM
by adev_ on 7/4/19, 6:33 PM
- This is human readable contrary to the JSON family and its {} abuses.
- It is not space / ident base contrary to YAML that becomes very quickly a mess to write and a mess to parse.
by NuSkooler on 7/4/19, 6:01 PM
If it's truly for end-users (read: non-admin/dev types), you probably shouldn't have them touching configuration files _at all_.
by markandrewj on 7/4/19, 9:53 PM
by KirinDave on 7/4/19, 7:55 PM
by choeger on 7/4/19, 6:18 PM
So the authors claim that their language is guaranteed to terminate for all well-typed programs. That is actually a nice spot for configuration languages. Yet, I wonder how
a) they guarantee it, as I have seen no obvious link to the language's semantics
b) useful this is in practice.
Nevertheless, very nice approach, indeed.
by mitchtbaum on 7/4/19, 7:20 PM
by ilaksh on 7/5/19, 5:03 AM
by voidmain on 7/4/19, 11:21 PM
by javier2 on 7/4/19, 10:59 PM
How small is a static binary to run this in my containers?
How are some ways to integrate the typed config in a language?
by arkh on 7/4/19, 9:45 PM
let input =
{ relative = "daughter"
, movies = [ "Boss Baby", "Frozen", "Moana" ]
}
by amingilani on 7/4/19, 10:11 PM
by mitchtbaum on 7/4/19, 7:06 PM
by desc on 7/4/19, 9:53 PM
Programmatic generation of static configuration files can be very useful.
Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned.
If you need to write a program to configure your program, you're probably doing it wrong.
by isoprophlex on 7/4/19, 6:06 PM
You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever.
Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables?
Might sound like I'm throwing sourness around, but I just don't see the niche for this, except inventing a new thing for the joy of it?
by _j7tr on 7/4/19, 5:46 PM