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

111–120 of 192 posts

Re: The Dhall Configuration Language

#111

Post by pdkl95 »

throwaway894345 wrote: post #11
6gvONxR4sf7o wrote: post #2

I love seeing useful languages that aren’t turing complete. Tooling gets much more interesting when you don’t have so many impossibility results around all the interesting stuff.

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

When you are using a regular language or deterministic pushdown automata, questions about the behavior or even asking if two implementations are equivalent is decidable. It is at lest possible8 to create software/tools to help answer the question "is this input safe." When you use a non-deterministic pushdown automata or stronger, you problem becomes provably undecidable*,

I highly recommend the talk "The Science of Insecurity"[2].

[1] https://en.wikipedia.org/wiki/Rice%27s_theorem

[2] video: https://archive.org/details/The_Science_of_Insecurity_ slides: [pdf] https://langsec.org/insecurity-theory-28c3.pdf

Re: The Dhall Configuration Language

#112

Post by dcchambers »

q845712 wrote: post #108
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…

just another 'have you looked at' : https://carvel.dev/ytt/ ytt lets you embed logic via a python-subset (starlark) and also provides "overlays" as a "replace/insert" mechanism. and all valid ytt files are valid yaml files, so they can be passed-through other yaml parsing stages.

Thanks for sharing! We've done a little experimenting with ytt (we already use several tools from Carvel/k14s, mainly vendir and kbld), but it's been a while...probably a year or more...since I've played with it. Need to give it another look.

Re: The Dhall Configuration Language

#113

Post by dcchambers »

bigcat12345678 wrote: post #107
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…

CUE's author invented Borg configuration language or BCL since 2008. BCL code is the 3rd largest human written code in Google internal code base. In 2019 Aprial, there is 180M lines of BCL, while C++/Java sits at ~300M. BCL configuration's large scale use probably is beyond any other infra as code use cases known to human. And the learning and ideas over more than a decade, is manifested in CUE. Personally, this is e…

Yeah, I really like what I've seen from CUE, and obviously the core team behind it is the real deal. I've never worked at Google but I've done quite a bit of research into Borg/BCL. AFAIK Jsonnet is basically a direct decedent of BCL, whereas CUE is the next evolution that tries to fix what BCL got wrong.

CUE was in its infancy when we were evaluating Jsonnet (and I wasn't even familiar with it at the time). If we were picking a data templating language today there's a good chance we would choose it. We very well may end up migrating to it or incorporating it in some way.

Re: The Dhall Configuration Language

#114

Post by Too »

bigcat12345678 wrote: post #107
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…

CUE's author invented Borg configuration language or BCL since 2008. BCL code is the 3rd largest human written code in Google internal code base. In 2019 Aprial, there is 180M lines of BCL, while C++/Java sits at ~300M. BCL configuration's large scale use probably is beyond any other infra as code use cases known to human. And the learning and ideas over more than a decade, is manifested in CUE. Personally, this is e…

Without knowing anything about Cue, just be careful with choosing to a technology only because it scales to the largest infra on earth, it doesn’t mean it scales equally good for smaller deployments.

Re: The Dhall Configuration Language

#115

Post by hsn915 »

Relying on configuration files to glue together a huge stack of tools and services in order to produce an end product is a huge mistake. I say it's a mistake fully knowing that nearly everyone in the industry is doing it.

Configuration is opaque. Undebuggable. Unmaintainable. By its very nature. No matter what "language" you use for it.

You should strive to keep configurable things to an absolute minimum.

Although it's worth making a distinction between "configurations" and "settings": when something is configured wrong, the application basically fails to operate as intended. For settings, there can't be "wrong" settings, all settings are valid, and if the input for a specific setting was invalid, the application can simply ignore it and use the default value. Example of a "setting": font size for a text editor. Example of configuration: the connection information for a database.

Re: The Dhall Configuration Language

#116

Post by thayne »

I like a lot of the ideas in dhall, but but I disagree with some of the design decisions.

The syntax for objects with dynamic keys seems unnecessarily verbose.

The arithmetic capabilities are very restricive. No subtraction, division, or modulo. Addition and multiplication only work on Natural. No numeric comparison. = And != Only work on booleans. There isn't really much motivation given for why it is so restricted.

Maybe I'm missing something, but it seems like if a type has a lot of optional fields, which is pretty common, you have to explicitly pass None for all of them. Maybe the pattern is to merge a default record with a smaller record that has what you actually want? But I didn't see any examples of that. Also, how do you deal with cases where null, and the absence of a value are treated differently? For example if leaving the value off means use the default and null means to turn a feature off. From what I can tell optinals are either always null or always absent when None.

It also seems like it would be annoying to have to specify types whenever calling functions like List/length.

IDK, maybe in practice these aren't as bad as they seem.

Re: The Dhall Configuration Language

#117

Post by plorkyeran »

bigcat12345678 wrote: post #107
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…

CUE's author invented Borg configuration language or BCL since 2008. BCL code is the 3rd largest human written code in Google internal code base. In 2019 Aprial, there is 180M lines of BCL, while C++/Java sits at ~300M. BCL configuration's large scale use probably is beyond any other infra as code use cases known to human. And the learning and ideas over more than a decade, is manifested in CUE. Personally, this is e…

> In 2019 Aprial, there is 180M lines of BCL, while C++/Java sits at ~300M.

It's... not obvious to me that that's a good thing? The ratio of configuration code to code in the things being configured being that close makes me think that BCL is something that's ill-suited to what it's now being asked to do but there's too much of it to realistically replace.

Maybe it's amazing and the problem it's solving is so complicated that even a language designed very well for solving that problem leaves you needing a lot of it, but I don't really consider "a staggeringly large amount of code has been written in this language" to necessarily be an endorsement of that language's quality. Citing Google's 300M lines of Java would also be a silly reason to pick Java in a project where you'll never interact with the Google ecosystem.

Re: The Dhall Configuration Language

#118

Post by Sahbak »

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…

Just my 2cents - ehen I started at current employer, we had a huge, convulted dhall project for kube. We ended up switching to a real language (python in our case due to reasons, Go is a more correct choice) and are very pleased with the results.

Re: The Dhall Configuration Language

#119

Post by Sahbak »

tr33house wrote: post #12

anyone using this for kubernetes config generation? What's been your experience?

Don't. Use helm, kustomize or a decent code language. Dhall will constrict, slow you down, make onboarding a nightmare, and ultimately be as brittle as other alternatives (Only it's harder to find where it broke). I cannot advocate against dhall enough.

Re: The Dhall Configuration Language

#120

Post by jordanbeiber »

hsn915 wrote: post #115

Relying on configuration files to glue together a huge stack of tools and services in order to produce an end product is a huge mistake. I say it's a mistake fully knowing that nearly everyone in the industry is doing it. Configuration is opaque. Undebuggable. Unmaintainable. By its very nature. No matter what "language" you use for it. You should strive to keep configurable things to an absolute minimum. Although it…

Wholeheartedly agree - convention before configuration wins with tooling even at modest scale.

Larger team(s) using free form yaml configuration and templating quickly becomes messy.

Setting a boundary at “configuration” and exposing configuration options to dev teams through settings works really well.

It requires you to have a tooling team with a few developers, but it scales!

Post reply on HN