The Dhall Configuration Language

Post by kqr » Fri, Jul 15, 2022, 6:08 AM UTC

plorkyeran wrote: post #117

bigcat12345678 wrote: post #107

Earlier quoted context omitted.

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 complic…

Post by thethethethe » Fri, Jul 15, 2022, 6:47 AM UTC

plorkyeran wrote: post #117

bigcat12345678 wrote: post #107

Earlier quoted context omitted.

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 complic…

Post by baby » Fri, Jul 15, 2022, 7:01 AM UTC

jordanbeiber wrote: post #120

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 by otabdeveloper4 » Fri, Jul 15, 2022, 7:50 AM UTC

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…

Post by makapuf » Fri, Jul 15, 2022, 7:59 AM UTC

fbn79 wrote: post #128

otabdeveloper4 wrote: post #127

Earlier quoted context omitted.

> a more robust tool using a more traditional language like Go I heard you liked configuration languages, so I wrote a configuration language for your configuration language. How long before you stick a Yaml config into your Go configuration library for easier maintenance? And so the cycle continues.

"Dhall... that you can think of as: JSON + functions + types + imports". Is this Typescript?