Earlier quoted context omitted.
How is it better than Jsonnet or Starlark?
Why are you implying that kccqzy thinks Dhall is better than Jsonnet or Starlark?
A new project should be better than the old ones. Otherwise, what's the point?
Dhall: A Non-Repetitive Alternative to YAML
101–110 of 181 posts
Re: Dhall: A Non-Repetitive Alternative to YAML
#102My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…
> one [of] the reasons that the industry moved away from XML was to have cleaner separation between data and logic
How is XML coupling data and logic? The only kind of "processing" it does by itself I can think of is composing documents from pieces and "processing instructions" as a generic extension mechanism. That is, features to support its original use case of authoring and capturing structured text. Now SGML has more processing features (tag inference, stylesheets/link processes, notations), but is still far away from Turing-completeness.
Re: Dhall: A Non-Repetitive Alternative to YAML
#103My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…
I 100% agree. It should be considered an important feature that my configuration files (and transfer data) don't suffer from the halting problem.
Re: Dhall: A Non-Repetitive Alternative to YAML
#104Earlier quoted context omitted.
Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated. Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple. Executable config, run during startup or, worse, on each request? NO. [edit] I think that's t…
Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.
Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration.
We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so it got fudged in deployment instead of being fixed in application design.
Re: Dhall: A Non-Repetitive Alternative to YAML
#105I love this!
How small is a static binary to run this in my containers?
How are some ways to integrate the typed config in a language?
Re: Dhall: A Non-Repetitive Alternative to YAML
#106Earlier quoted context omitted.
Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.
Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration. We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so…
If you operated services that should run at scale, or 24/7, or both, you must have noticed that the ability to fix an urgent issue (which may be totally not a fault of the deployed code) by changing just configs is valuable.
Re: Dhall: A Non-Repetitive Alternative to YAML
#107How far does "non turing completeness" really get you in this context? It looks easy to write a program in this language that will take longer than the age of the universe to evaluate and whose result can't be represented explicitly without collapsing the galaxy into a black hole. How much comfort can you take in the fact that you know it doesn't diverge?
Re: Dhall: A Non-Repetitive Alternative to YAML
#108Earlier quoted context omitted.
Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration. We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so…
If you operated services that should run at scale, or 24/7, or both, you must have noticed that the ability to fix an urgent issue (which may be totally not a fault of the deployed code) by changing just configs is valuable.
Of the failure modes I've had to deal with, even when we did use a lot of interpreted scripts which could be live-patched, very few of the important issues were fixable that way. Because the stuff which broke was rare and deep.
One could argue that everything would be config-related if all the code were interpreted and considered to be configuration. So absolutely everything could be fixed in Production.
I'd argue that absolutely everything could be broken in Production too, in that case. The point is that you test the invariant stuff, and have a small surface area of variables which define the permutations of Live behaviours.
Configuration is not code. Code gets tested and doesn't vary between Canary, Nightly, Stable Test, Customer Test and Customer Live for a given build.
Because some of us build stuff for customers who won't justify the 'risk' of updating every day, and have upgrade cycles measured in months.
Re: Dhall: A Non-Repetitive Alternative to YAML
#109Couple 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 tried to introduce Jsonnet at our org. It failed miserably because ops kept mistaking the name for JSON which they hated. (International multilingual team).
It was a real shame because ops then implemented some features of Jsonnet via scripts to to parse and merge YAML. What was 0 LOC in Jsonnet is now about 300 LOC plus custom CI checkers, all because of a marketing problem.
Re: Dhall: A Non-Repetitive Alternative to YAML
#110My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…
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 framework.