Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dhall Configuration Language

dhall-lang.org

Post reply on HN
Print view View original

41–50 of 192 posts

Re: The Dhall Configuration Language

#41

Post by dcchambers »

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 from perfect, but it gets the job done pretty well and has been relatively easy for engineers across the company to pick up.

That said, after a 3+ year journey, the shortfalls in our original design have become more noticeable and we're giving more thought to writing a more robust tool using a more traditional language like Go to solve some of our configuration/deployment and data templating problems.

Cue^2 is something I'm keeping an eye on these days as well.

[1]: https://jsonnet.org/

[2]: https://cuelang.org/

Re: The Dhall Configuration Language

#42

Post by jonathanyc »

I wonder if a version of Python with types with some way to force programs to be total would be a 'good enough' substitute. JavaScript has `"use strict";`, `# use total` could ban recursion and loops over non-constants. You'd have to work hard to ensure things were really total, e.g. ban assigning functions to variables, but maybe you could make it hard enough to pay off.

Re: The Dhall Configuration Language

#43

Post by CameronNemo »

sshine wrote: 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/

Re: The Dhall Configuration Language

#44

Post by lilyball »

aendruk wrote: post #27
cbb330 wrote: 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 too spent the whole time scrutinizing the syntax and ignoring the values, since this is an intro to the language and not to Bill’s dotfiles. I was ultimately unable to deduce the presumed syntax error and independently came to the same misconclusion.

It can't be a syntax error though as it evaluates successfully as demonstrated by the right-hand side.

Re: The Dhall Configuration Language

#45

Post by brigandish »

svnpenn wrote: 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

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).

Re: The Dhall Configuration Language

#47

Post by gre »

suby wrote: post #30
TylerE wrote: post #23

Earlier quoted context omitted.

How about not making the very first thing on the page a confusing puzzle?

They should at least reveal the answer somewhere immediately close by. I couldn't spot the error after a few minutes, came to the comments to find out what it was. Not a great introduction because you're asking someone to spot an error in something they don't know the syntax or ruleset for. The project looks cool though.

Change the name from Bill to John/Jhon. That's more obvious than all the barcode characters next to each other.

Re: The Dhall Configuration Language

#48

Post by lilyball »

corrral wrote: post #40
edflsafoiewq wrote: post #38

Earlier quoted context omitted.

Config is a type, so it's type is Type.

Figured, but it's a pretty goofy way to introduce it after that comment. [EDIT] I mean, you can almost "who's on first?" this. "OK, what type do you want this to be?" "Type." "Yes, what type do you want it to be?" "Type." "Great, ok, yes, the type , what type is Config?" "Type." "WHAT IS THE NAME OF THE TYPE YOU WANT CONFIG TO BE???" "Type." flips desk

Is it? My takeaway is "oh cool, first-class types". Experimenting with this, I can write the following:

  let ConfigOf : Type -> Type = \(type : Type) ->
        {- What happens if you add another field here? -}
        { home : type
        , privateKey : type
        , publicKey : type
        }
  
  let Config : Type = ConfigOf Text
and the rest of the example still works and evaluates the same.

Also in a later example it has the expression `generate 10 Config buildUser`, which also works because of first-class types. Instead of needing generics, you just take a type as a regular parameter.

Re: The Dhall Configuration Language

#49

Post by CameronNemo »

junon wrote: 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.

They are trying to tell a story about how Dhall helps you avoid hard to notice errors, but they aren't doing a great job.

Would be cool if they had a three panel story:

* using json with the typo

* using dhall with the typo

* using dhall with variables to avoid the typo

Might be easier to understand.

Re: The Dhall Configuration Language

#50

Post by lytedev »

fridental wrote: post #46

Why wouldn't you use Python as your configuration language?

I believe you may want a non-turing complete language for strict configuration.

But sometimes, as you indicate, you want VERY dynamic configuration. But I would argue then that such logic goes in your application itself and is not in fact part of your configuration.

Post reply on HN