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

81–90 of 192 posts

Re: The Dhall Configuration Language

#81

Post by na85 »

Ixiaus wrote: post #36
_ofdw wrote: 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 too don't want to or would use a bash script as a config file. That's the point of dhall: you get good static types and it's not turing complete, so you get a lot of the safety and code reusability tools without the pitfalls of a general purpose programming language. And, have you ever worked with giant configs in json or yaml? It becomes incredibly painful to manage.

I prefer to use multiple, smaller config files to keep them manageable.

Re: The Dhall Configuration Language

#82

Post by throwaway894345 »

eru wrote: post #52
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.

In theory that's true for many of the kinds of Turing-incomplete languages we care about. (Eg it's not true for JPG or for (proper) regular expressions.) From Dhall's docs (emphasis mine): > Note that a “finite amount of time” can still be very long. For example, there are some short pathological programs that take longer than the heat death of the universe to evaluate. The main benefit of evaluation being finite is…

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 the static type system which is sadly uncommon among configuration languages.

Re: The Dhall Configuration Language

#83

Post by Blackthorn »

I really hope that one day Google can open source GCL, which so many languages have been inspired by without ever really being as good as it is. They all claim to address pitfalls in GCL but at the end of the day they're just worse than GCL.

Re: The Dhall Configuration Language

#84

Post by vosper »

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…

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

You might want to give Pulumi (no affiliation) a look. I've been using it with Typescript, but it supports Go, too.

Re: The Dhall Configuration Language

#85

Post by Blackthorn »

fridental wrote: post #46

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

Sometimes you just explicitly want to output text or a structured format, but you'd rather have a template language do it because it being a lot less powerful actually makes it easier to write close to the output format.

Re: The Dhall Configuration Language

#86

Post by rtpg »

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, then run into the fact that people really do want dynamic systems with some abstraction capabilities, and then have to overlay that into their systems.

Re: The Dhall Configuration Language

#87

Post by labster »

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.

Yeah, I spent 3 minutes looking for a syntax error in 5 lines of code. I couldn’t find anything. I’m obviously too dumb to figure out this language so I guess I’ll just stick with YAML.

Re: The Dhall Configuration Language

#89

Post by rtpg »

jonathanyc wrote: post #42

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.

Starlark is a version of this, and it's used by Bazel in particular. It's very cool tech, and sidesteps the difficulties of ensuring Python works without shipping a specific Python interpreter.

Re: The Dhall Configuration Language

#90

Post by benlivengood »

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

My biggest pain when doing this is: set up an environment configuration. Then set up a test or stage environment that matches it. Then modify the environment over the next few years keeping the stage and production environment configs in sync so that testing and validation are useful (the stage configuration actually matches production so that success or failure in staging predicts the same in production) before going to production.

Even something as simple as variable substitution becomes very useful in these cases so that configuration can be a single file and substitution delivers the staging or production config. Functions and operators allow more complicated configurations to remain DRY. Checks prevent the stage servers from using the production database connection string, etc.

Post reply on HN