I’m completely new to dhall but I really like what I’m seeing so far playing with it. One thing that I don’t have a good idea about after reading docs/tutorials is the validation story and what is the suggested path to take here.
By validation I mean things like:
- Make sure that opacity field in the final config is 0 <= opacity <= 100
- Make sure that minReplicas <= maxReplicas
For this simple case I saw Assertions, but I also saw it mentioned that these only execute at type-checking time - which I don’t fully understand consequences of.
I can see how the validation could require things that are outside of the scope of the language:
- remote calls to validate that referenced entities exist
To me the configuration as code is great but it requires a validation layer that allows to express more than what the type system provides. The problem with this is that if we require another language to run the validations on the final object outputted by dhall (say Python or Kotlin) then there is always a question: why not use the same language to describe the configuration in the first place - it’s much simpler for the end user, they have to learn one (say Python) instead of two (dhall + Python) languages and config creation and config validation share exactly the same representations in code. Of course I understand the advantages that dhall provides (like no being Turing complete) that brought me to it in the first place but I just feel it’s not a complete ecosystem without validations. Would really love to know your thoughts on this!