Dhall is fantastic and I try to encourage everyone in tech I meet try it.
OK, why ?
Because it is a good mix of features, syntax, execution speed and correctness.
Of course. Didn't you read the article?
Dhall: A Non-Repetitive Alternative to YAML
111–120 of 181 posts
Re: Dhall: A Non-Repetitive Alternative to YAML
#112I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy. 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 a…
> Moreover it has (safe) imports which make defining constants quite easy.
I read about dhall’s imports, and I don’t think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a “safe” configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives the same output unless I explicitly change an input. Pulling a prelude off of github does misses several of these requirements.
(Having your config file fail to parse if your network is down is bad, bad news if that config is needed to bring your network up. It’s also bad news if a parsing failure due to a transient network issue leaves your system in a state where it won’t quickly recover if the network comes back.)
Re: Dhall: A Non-Repetitive Alternative to YAML
#113If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete. 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…
One valuable point of Dhall is that it is programmable (yet not TC) in such a way to that you can e.g. describe a whole system entirely in Dhall and then (in Dhall!) derive whatever further configurations (plural!) you need from that. This is much more feasible than in e.g. YAML because Dhall is strongly typed. So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with al…
I mean, jq is a powerful programming language. Did you look at the link I posted?
Re: Dhall: A Non-Repetitive Alternative to YAML
#114Earlier quoted context omitted.
Recursion is fine, as long as an argument gets smaller at every iteration, since that guarantees termination.
Oh, like Ackermann function[0]? Because I wouldn't want my server try to evaluate that. [0] https://en.wikipedia.org/wiki/Ackermann_function
Exactly.
And heck, even with loops that are guaranteed to terminate, you can loop long enough to have that be a problem.
You really want to have no loops at all, like DTrace and eBPF, or else you want to give up on this idea of not being Turing-complete. You have to decide how critical it is to be able to put a reasonable bound on the run-time of a function.
Re: Dhall: A Non-Repetitive Alternative to YAML
#115Couple of contenders: - 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 comp…
Cue is a bit too cute trying to combine the subtyping and inhabitance relations into one.
What problems do you see?
Re: Dhall: A Non-Repetitive Alternative to YAML
#116Couple of contenders: - 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 comp…
We make heavy use of Jsonnet at work (https://databricks.com/blog/2017/06/26/declarative-infrastru...). It's worked great. Having a hermetic, pure templating system whose only output is a set of JSON/YAML files means that you can refactor fearlessly: as long as the materialized JSON/YAML doesn't change, you are 100% sure your refactor is safe. Bazel's StarLark dialect of Python (https://github.com/bazelbuild/starlark) has similar benefits.
The language is simple and remarkably well specified, enough that we implemented our own intellij plugin (https://plugins.jetbrains.com/plugin/10852-jsonnet) and even our own faster compiler (https://github.com/databricks/sjsonnet) without much effort at all.
There are odd corners in the language, but not something that most people will end up bumping into in typical usage. The templates certainly get messy in large configurations, but no more messy than any other code, and the hermeticity/purity greatly helps in managing the messiness. It's certainly less messy/odd than the copy-paste configs or be-spoke JSON/YAML templating systems that inevitably appear in messy deployment environments!
The last thing of note is the lack of static types: this definitely affects usability to some extent, and especially hinders IDE support from being as useful as it is in e.g. Java. But having a useful/ergonomic type system that fits this specific problem space is probably still an unsolved research question.
Re: Dhall: A Non-Repetitive Alternative to YAML
#117Couple of contenders: - 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 comp…
My favorite is still the nginx config-like libucl: https://github.com/vstakhov/libucl
Re: Dhall: A Non-Repetitive Alternative to YAML
#118Earlier quoted context omitted.
None of the examples show quoting via ticks, that seems to be a pretty obscure feature.
Actually, at least one does and for the wrong reason (an attribute named True, for example, needs to be quoted): { -- Unlike YAML, Dhall does not accept YES|NO|ON|OFF validDhallBools = [ True, False ] , someNumbers = [ 1 , -- Dhall is not indentation-sensitive 2, 3 ] -- Field names that conflict with reserved identifiers must be quoted , `True` = True , version = "9.3" {- Strings must be quoted All Dhall literals hav…
Thanks, I'm surprised I missed that!
Re: Dhall: A Non-Repetitive Alternative to YAML
#119So far, only comments complaining about syntax. You can do better, HN!
[deleted]
Re: Dhall: A Non-Repetitive Alternative to YAML
#120Earlier quoted context omitted.
Not being Turing-complete is a feature. A Turing-complete language allows to write programs that never terminate. This is not what a config file should be capable of.
Previously in my career I've abused Jinja templating to build "scripts" out of Ansible and SaltStack YAML. It solved business problems effectively but I'm sure when I left that role I passed on a big plate of spaghetti to my successor with minimal automated tests. If it depends on conditional logic or iteration, it probably belongs in a proper programming language with a linter, type checkers, debugger and unit test…
This is one of the reasons why, coming from a background of writing Chef and writing exhaustive testing around my configuration management, I've never been able to deal with Ansible without grinding my teeth. Or, for that matter, Terraform; HCL is godawful and trying to write it in JSON is a sucker's bet, too. With the move towards more containerized systems I don't write Chef much anymore (thankfully), but Terraform has become ever more of a boil on my rear end. Fortunately there's also Pulumi now and writing this stuff in TypeScript is a lot faster and feels really good.