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

161–170 of 192 posts

Re: The Dhall Configuration Language

#161

Post by rad_gruchalski »

hsn915 wrote: post #147
eru wrote: post #138

Earlier quoted context omitted.

> Configuration is opaque. Undebuggable. Unmaintainable. By its very nature. No matter what "language" you use for it. What makes you think so? How do you define configuration? I mean, in the extreme case you can see Python as a configuration language for the behaviour of the Python interpreter. Does that make Python a configuration language? Where do you draw the line?

Configuration is some sort of information that is stored in a text file, for reading by one or more programs, where these programs cannot meaningfully operate without this critical information in the configuration files. If you have ever worked in the web startup industry, their use is endemic in everything. You often cannot deploy any web applciation without properly understanding tons of configuration files. Becaus…

> Because to understand the configuration files, you have to understand the programs they are inteded for and the environments they end up in, and the language they are written in.

Seems like the right approach. To use something, one has to understand how to use it. Why is this unusual?

Re: The Dhall Configuration Language

#162

Post by bbkane »

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…

We use https://github.com/octodns/octodns for some of our DNS records. It's flexible, much faster than Terraform for thousands of records, and the maintainer Ross has been responsive on issues and pull requests. Also see Cloudflare's blog for how they use it

Re: The Dhall Configuration Language

#163

Post by rtpg »

thethethethe wrote: post #157
rtpg wrote: post #86

I think Dhall is good at pushing forward some ideas, but honestly I feel like Skylark (Python but not turing complete) just feels like the right way forward. Being able to specify dynamic functionality in a configuration file, when paired with a good configuration API, really makes stuff straightforward IMO. Gunicorn is the best example of this. We have all of these tools that try to propose declarative configuration…

Is skylark (now called starlark btw) general purpose? Its my understanding that its largely used for configuring bazel.

https://github.com/google/starlark-go

Re: The Dhall Configuration Language

#164

Post by bbkane »

SomaticPirate wrote: post #94

Used this for a fairly complex, large project. It really is Haskell for configuration language and undoubtedly superior than YAML. But for my grug brain, function currying and the lack for loops made it hard. Functional languages continue to be a great place to steal from but pure functional requires warping your brain quite a bit. Maybe Tanka is more my style

Also look into Starlark or Cue

Re: The Dhall Configuration Language

#167

Post by throwaway894345 »

eru wrote: post #134
throwaway894345 wrote: post #82

Earlier quoted context omitted.

I guess I don’t care much if a configuration language takes a long time in some pathological case (a user writes a loop that doesn’t terminate). Such cases are already too rare to justify a dedicated language. And if the concern is bad actors, then a bad actor wouldn’t have to try to hard to get a Dhall program to run for a long time (copy paste something from the Internet). The more compelling reason to use Dhall is…

Infinite loops are a pretty common bug in my experience. (Same for the recursive equivalent.)

So common that it justifies a change of language? "Oops, this thing that should have run for 5s has run for 30s, something must be wrong, ". You can even automate that reasoning by way of a timeout. In a hypothetical world where I'm choosing between two otherwise exactly equal configuration languages, I suppose this would give the advantage to Dhall, but honestly I'd probably pick TypeScript because making an entire org learn a new syntax is far more trouble than that saved by non-Turing-completeness.

Re: The Dhall Configuration Language

#168

Post by eru »

valenterry wrote: post #142
eru wrote: post #136

Earlier quoted context omitted.

> The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. That's a very brittle restriction at best, and if implemented strictly on time, it's a very flaky on as well.

How so? Normally, generating a config, even a big one, is a matter of milliseconds even for slow languages. We are not talking about applying the config - we are just talking about using some inputs (variables) and generating a string / text-file that we return to the entitiy that then validates and uses the config. Not sure why that would be flaky.

Flaky in the sense that you can have stuff that's fitting right into your cut-off time limit on some runs, and going over on some others.

Re: The Dhall Configuration Language

#169

Post by throwaway894345 »

pdkl95 wrote: post #111
throwaway894345 wrote: post #11

Earlier quoted context omitted.

What practical advantages are there? Someone can always write a program that runs until the heat death of the universe even in a Turing-incomplete language.

> What practical advantages are there? The major advantage of a language that isn't Turing complete is not having the major risk inherent to Turing complete languages: asking if any non-trivial program will produce any given result or behavior is undecidable [1]. > write a program that runs until the heat death of the universe even in a Turing-incomplete language. The Halting Problem is just a simple example of progr…

> The major advantage of a language that isn't Turing complete is not having the major risk inherent to Turing complete languages: asking if any non-trivial program will produce any given result or behavior is undecidable[1].

It's not obvious to me that I should care about this property in a configuration language. For a given configuration use case, I probably have a good idea about the extreme upper-bound for a correct program--say, 5s. If the program runs for 30s, the supervisor kills it.

> The Halting Problem is just a simple example of program behavior. The undecidability extends to any other behavior. Asking if a given program will behave maliciously is still undecidable even if we only consider the set of programs that do halt in a reasonable amount of time.

What's a malicious action in a configuration use case that a Turing complete program could muster but not a non-Turing-complete program?

Re: The Dhall Configuration Language

#170

Post by remram »

dcchambers wrote: post #41

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…

jsonnet seemed like a great idea to me, but I've experienced extremely low performance. My Kubernetes manifest with a couple hundred lines of code in 4 files, which rendered instantly in Python before and renders instantly now with Helm, would take 10-20s with jsonnet. The "lazy evaluation" would probably go into some quadratic or exponential behavior, evaluating the same thing many times, but I sure couldn't see why (it was very straightforward code) or where (no debug tools...).

I really wouldn't use it for anything until tooling improves (but then against I'd much rather use something like Starlark).

Post reply on HN