Live data from Hacker News

The Dhall Configuration Language

dhall-lang.org

71–80 of 192 posts

Re: The Dhall Configuration Language

#71
post #17
post #10

> Can you spot the mistake? Nope, so now I have no incentive to use your config format because it's established something is wrong and it's completely non-obvious. Thanks for not wasting my time, I guess.

This opinion is ironic because this is exactly what the author intended to describe -- the typo IS hard to find. The "Hello, World" example is nothing more than JSON, showing a string repeated 3 times. On the third time, "bill" is misspelled with "blil". The next tab shows how Dhall uses a variable definition to prevent this type of error.

Sure, but how do I know that the user doesn't store their public key in /home/blil?

Re: The Dhall Configuration Language

#72

I work on a deployment tooling team. In 2019/2020 we did a deep dive into Dhall vs. Jsonnet^1 for standardizing config and kubernetes templating across my company (Zendesk). We ended up going with Jsonnet (although some Dhall evangelists in the company have kept the dream alive!), which I think is a more approachable language for many, but Dhall has a lot of cool features and good things going for it. Jsonnet is far…

> using a more traditional language like Go to solve some of our configuration/deployment and data templating problems. Have you looked at https://github.com/kris-nova/naml ? :)

I had not seen that but it looks super interesting and potentially useful! Thanks for sharing!

Re: The Dhall Configuration Language

#73
post #24
post #17

Earlier quoted context omitted.

This opinion is ironic because this is exactly what the author intended to describe -- the typo IS hard to find. The "Hello, World" example is nothing more than JSON, showing a string repeated 3 times. On the third time, "bill" is misspelled with "blil". The next tab shows how Dhall uses a variable definition to prevent this type of error.

I took it to mean "can you find the syntax error". It wasn't clear they meant the text

Yeah, I eventually caught it but wished I hadn't wasted my time on it - seems like something they could better have shown with an animation

Re: The Dhall Configuration Language

#74
post #31

Apparently I'm in the minority that feels config languages should be little more than namespaces and key-value storage and should not be programmable. I would not want to use a bash script as a config file, for example.

I think more programming power is useful in the service of stopping bugs; for instance, you could have a language where the part that "does stuff" isn't Turing complete, but the part that "stops incorrect stuff from happening" (the type system) is.

Re: The Dhall Configuration Language

#75
post #19

Dhall is my favorite configuration language that I never get around to using. I manage DNS in Terraform, and since every Terraform provider uses different objects definitions, and every object definition is rather verbose, Dhall would be a way to specify my own DRY types and leave the provider-specific details in one place. Adding new DNS entries and moving several domains between providers would be a matter of chang…

I use tanka/jsonnet and cringe everytime I read a helm chart. Type safety would be nice, but the k8s api can verify the validity on the server. https://tanka.dev/

tanka helped me make peace with k8s (yaml) or at least made for a good learning environment for k8s than the other options. Wonder about other peoples experience or their rite of config tool passage

Re: The Dhall Configuration Language

#76
post #59

Earlier quoted context omitted.

I much prefer this style, I use it wherever I can because I can comment out lines without a trailing comma causing a syntax error. SQL, Ruby… wherever I can. Try it, I doubt you'll go back (unless someone's stupid parser doesn't let you).

You can do the same, if your language allows a final comma. (And that's what the comment you reply to suggests: make Dhall allow a final comma.)

What's the point of allowing a trailing comma? A delimiter symbol is a delimiter symbol, be it a an opening curly brace or a comma between elements, and one can simply align delimeters.

Re: The Dhall Configuration Language

#78
post #5

{ home = "/home/bill" , privateKey = "/home/bill/.ssh/id_ed25519" , publicKey = "/home/blil/.ssh/id_ed25519.pub" } This is the most awkward abuse of formatting I've seen in a long time. Just allow/require a final trailing comma, and this nonsense goes away

Yeah, I also really dislike this mixing up of indentation levels because of a language limitation. The "{" denotes a container, and the "," a separation between items of said container, for me it makes sense for them to be nested a level deeper

both symbols are delimiters, one can choose to align them together even when they are not the same character. Opening and closing braces aren't the same character either, but people have been aligning them for ages, I don't see a reason why commas, while being part of the same expression, should not follow the same principle.

Re: The Dhall Configuration Language

#80

I work on a deployment tooling team. In 2019/2020 we did a deep dive into Dhall vs. Jsonnet^1 for standardizing config and kubernetes templating across my company (Zendesk). We ended up going with Jsonnet (although some Dhall evangelists in the company have kept the dream alive!), which I think is a more approachable language for many, but Dhall has a lot of cool features and good things going for it. Jsonnet is far…

I like Dhall for what it gives you with type safer etc but the compile times are extremely slow on a large project and type signatures can get real long/hard. It is bit of a Dhall monolith though ;)
Post reply on HN