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

171–180 of 192 posts

Re: The Dhall Configuration Language

#171

Post by dcchambers »

remram wrote: post #170
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…

> jsonnet seemed like a great idea to me, but I've experienced extremely low performance.

Although each implementation of jsonnet has some quirks, take a look at sjsonnet^1 (scala-based) or go-jsonnet^2 for improved performance. We generally prefer go-jsonnet.

There's also a Rust version^3 that claims to be the fastest yet^4, but I haven't experimented with it at all.

[1]: https://github.com/databricks/sjsonnet

[2]: https://github.com/google/go-jsonnet/

[3]: https://github.com/CertainLach/jrsonnet

[4]: https://gist.github.com/CertainLach/5770d7ad4836066f8e0bd91e...

Re: The Dhall Configuration Language

#172

Post by zeven7 »

eru wrote: post #137
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…

For the record, when I was an SRE at Google, most people I talked to hated BCL with a passion.

It was in fact the running joke that everyone knew everyone hated BCL.

But the issues with it were well known, so it makes sense to me that after learning all that the guy who invented it could have come up with a really good successor.

Re: The Dhall Configuration Language

#173

Post by baby »

valenterry wrote: post #131
baby wrote: post #125

Earlier quoted context omitted.

Convention over configuration is really the future, but not everything follows that philosophy. For example, OCaml codebases are basically a free for all and you can organize things however you want. So with that in mind, you need something to organize and build.

Convention seems to be nice in the beginning. But it's very hard to maintain. Much better is default configuration. I.e. all "conventions" are explicitly generated into a default-configuration file which you can then change/overwrite/update in whatever way you want.

I think you can have both (for example, go and rust starter projects)

Re: The Dhall Configuration Language

#174

Post by valenterry »

ghostwriter wrote: post #153
valenterry wrote: post #142

Earlier quoted context omitted.

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.

Generating a config may include downloading a number of remote definitions, their evaluation & caching for future reuse (Dhall does that, Nix too), which doesn't fit into milliseconds threshold on the first run.

Potentially yes. But if we compare it to Dhall, then the sandbox would just allow to generate a config, potentially based on some inputs, but without disk access, network access, etc.

If you allow that for Dhall, then you also have the problem of a config potentially taking extremely long to load / to be ready. So you will want to set a timeout anyways and I don't see a big difference here from a practical point of view.

Re: The Dhall Configuration Language

#175

Post by valenterry »

eru wrote: post #168
valenterry wrote: post #142

Earlier quoted context omitted.

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.

I mean, theoretically yes - but I doubt that this would be an issue in any but the rarest cases.

Re: The Dhall Configuration Language

#176

Post by oq_computer »

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…

This is actually one of my main concerns with CUE and something I'd like the community overall to keep in mind. There is a high chance in my opinion that CUE ends up being adopted as a silver bullet for configuration just for being cargo culted as something that is from Google and the drive for dependence by open source users sometimes, sort of similar to what happened with Kubernetes. That modules and package management in CUE are modeled after what Go did is also questionable IMO but makes sense since the project is Go based. CUE is a good tool for validation and has its uses, but Dhall has some really neat innovations that make it an exciting project so worth looking at both at least and compare first.

Re: The Dhall Configuration Language

#177

Post by remram »

dcchambers wrote: post #171
remram wrote: post #170

Earlier quoted context omitted.

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…

> jsonnet seemed like a great idea to me, but I've experienced extremely low performance. Although each implementation of jsonnet has some quirks, take a look at sjsonnet^1 (scala-based) or go-jsonnet^2 for improved performance. We generally prefer go-jsonnet. There's also a Rust version^3 that claims to be the fastest yet^4, but I haven't experimented with it at all. [1]: https://github.com/databricks/sjsonnet [2]:…

14s to 2s, pretty large improvement! Thanks for the recommendation.

Re: The Dhall Configuration Language

#178

Post by remram »

fbn79 wrote: post #166
makapuf wrote: post #129

Earlier quoted context omitted.

IIUC, Dhall is pure and have no side effects

so something like using typescript on Deno without extra permissions?

"Pure" means something specific for programming languages: https://en.wikipedia.org/wiki/Pure_function

Re: The Dhall Configuration Language

#179

Post by remram »

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.

It is used by other tools like Tilt https://tilt.dev/ (a Kubernetes dev tool)

Re: The Dhall Configuration Language

#180

Post by avodonosov »

mixedCase wrote: post #69
avodonosov wrote: post #68

JSON is a strange choice, with all those unnecessary commas. S-exprs / EDN would be a better choice, especially as this is a functional language.

Strange choice for what? It's just one of the compile targets.

> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports

At the top of the main page.

See also the Hello World and other examples.

Post reply on HN