Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dhall: A Non-Repetitive Alternative to YAML

dhall-lang.org

Post reply on HN
Print view View original

131–140 of 181 posts

Re: Dhall: A Non-Repetitive Alternative to YAML

#131

Post by solatic »

jrudolph wrote: post #124

Dhall is an awesome tool to have in your DevOps tool belt - we're heavy dhall users at meshcloud [0] and couldn't be happier about it. We picked it after evaluating a long list of contenders (yaml madness with anchors, jsonnet, ksonnet, j2/jinja, a hacked ejs compiler [1] and some more I forgot). It's so good we're looking into how we can give back/donate to the project. Dhall elegantly solves a major challenge: conf…

We're also heavy Dhall users in production. Functional, strongly typed configuration is such a powerful concept that I struggle to understand how the language isn't more popular yet.

Common example: let's say I want to set up a PostgreSQL database for a service running in Kubernetes in AWS. How best to get it done?

Well, it turns out there's a number of different options: you can set up a DB through RDS, and a service in Kubernetes which directs to it through an externalName, which is probably what you want in production; you can set up Postgres as a StatefulSet, which is probably what you want in an ephemeral testing environment; or maybe you have a customer with a full-time DBA who will create the database for you and give you a connection string.

With Dhall, you set up a union type with each of these scenarios as options, and then you have a Dhall function for your Terraform and Kubernetes configurations. In your Terraform configuration, you have an RDS module where the count is set to 1 for the RDS/production scenario and 0 otherwise. In your Kubernetes configurations, you set up a service with an external name appropriately when you need to, set up a StatefulSet when that's relevant, etc.

Because they all use the same type in their function's parameter, they're guaranteed to stay consistent. You're guaranteed to never have an RDS instance setup alongside a Postgres StatefulSet. If you need to make changes (add options, change options, etc.) then you will get type errors in each and every place which forces you to address them, including in places you forgot about.

We started to adopt Dhall more than half a year ago now and we've barely scratched the surface of what the language makes possible. Purity in infrastructure and operations is a powerful drug.

Re: Dhall: A Non-Repetitive Alternative to YAML

#132

Post by guggle »

hjk05 wrote: post #126

This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that…

> i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity.

Well... I'd argue that when using Python I don't feel the need for a config file language in the first place... it's human friendly enough and I don't have to learn another syntax, use another parser, etc. I had to work on a Symfony project recently and I wish it wasn't sprinkled with all those yaml files.

> I’ve never caught myself thinking “if only there was a nice way to limit myself to a non Turing complete subset of python/Haskell”

Ditto... seems like bloat to me. There may be some use cases I don't know about but these config file languages tend to repel me.

Re: Dhall: A Non-Repetitive Alternative to YAML

#133

Post by HelloNurse »

eridius wrote: post #129
hjk05 wrote: post #126

This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that…

That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.

On a practical level, C is an alternative to assembly because the appropriate black-box tools and combinations of tools allow the user to easily turn source code in either Language or a combination of both into an executable.

Generating assembly from C is an implementation detail, and many C compilers don't do that.

On the other hand, Dhall really is a YAML generator: the available tools allow only one-way conversion (in particular, there is no interpreter/library to ingest Dhall from the configured application itself).

Re: Dhall: A Non-Repetitive Alternative to YAML

#134

Post by guggle »

isoprophlex wrote: post #13

To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound…

My thoughts, exactly. Especially with dynamic, scripting languages with no need for compilation and simple enough syntax (ie. php, python, ruby, etc). Why would I want to add another layer of complexity to an application with an unknown language while I already have a capable one ? Why add more dependencies on your project ? Why add more cognitive load on your brain ?

Re: Dhall: A Non-Repetitive Alternative to YAML

#135

Post by GordonS »

KirinDave wrote: post #111
GordonS wrote: post #97

Earlier quoted context omitted.

OK, why ?

Because it is a good mix of features, syntax, execution speed and correctness. Of course. Didn't you read the article?

I did, and it's bad form to suggest otherwise.

I was asking about your personal opinion, since you said it was great but didn't give any info as to why.

Re: Dhall: A Non-Repetitive Alternative to YAML

#136

Post by eridius »

HelloNurse wrote: post #133
eridius wrote: post #129

Earlier quoted context omitted.

That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.

On a practical level, C is an alternative to assembly because the appropriate black-box tools and combinations of tools allow the user to easily turn source code in either Language or a combination of both into an executable. Generating assembly from C is an implementation detail, and many C compilers don't do that. On the other hand, Dhall really is a YAML generator: the available tools allow only one-way conversion…

Dhall is also a JSON generator. And you could write your own Dhall implementation that lets you consume it directly from an application if you want to, it's just nobody's considered that worth doing.

Re: Dhall: A Non-Repetitive Alternative to YAML

#137

Post by oalessandr »

amluto wrote: post #112
oalessandr wrote: post #73

I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy. There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes . The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible a…

> Moreover it has (safe) imports which make defining constants quite easy. I read about dhall’s imports, and I don’t think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a “safe” configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives th…

I get your point, but you don't need to run imports over the network (local imports are fine).

Also, if you were to import over the network, by running `dhall freeze` a semantic hash of the content is computed so you are 100% sure that what you are importing is not going to change. Moreover, files that have a hash value will be cached by dhall.

If you don't want to bother with copying over Prelude and you don't trust the cache, you can also normalize the code before pushing it to the network. This will flatten all your imports and reduce your file to normal form.

You might be interested in what they say about imports here: https://github.com/dhall-lang/dhall-lang/blob/master/standar...

Re: Dhall: A Non-Repetitive Alternative to YAML

#138

Post by comex »

nine_k wrote: post #88
markandrewj wrote: post #86

My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…

Not being Turing-complete is a feature. A Turing-complete language allows to write programs that never terminate. This is not what a config file should be capable of.

Of all the bugs you've ever dealt with in programs in general, what fraction of them of them were infinite loops?

For me I'd guess maybe... 0.1%? It's definitely under 1%.

Given that, it makes no sense to me that I'd want to make myself jump through hoops to express some basic coding patterns [1], just to rule out that single class of bugs. It seems like a solution in search of a problem.

[1] https://github.com/dhall-lang/dhall-lang/wiki/How-to-transla...

Re: Dhall: A Non-Repetitive Alternative to YAML

#139

Post by jose_zap »

amluto wrote: post #112
oalessandr wrote: post #73

I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy. There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes . The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible a…

> Moreover it has (safe) imports which make defining constants quite easy. I read about dhall’s imports, and I don’t think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a “safe” configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives th…

You can still do that, though. In Dhall you may import things remotely as you develop and then tell Dhall to pre-fetch the result, you can commit that and it will not access anything.

You may also just download any imports yourself and source them locally.

Additionally Dhall supports import fallbacks, for example you may try first a remote import, and if it fails it will look for another place, which I’ve could be remote or local. This is a good strategy for developing locally and then committing imports for production use.

You can also, of course, host the files in your local network.

Re: Dhall: A Non-Repetitive Alternative to YAML

#140

Post by comex »

mbrock wrote: post #128
voidmain wrote: post #107

How far does "non turing completeness" really get you in this context? It looks easy to write a program in this language that will take longer than the age of the universe to evaluate and whose result can't be represented explicitly without collapsing the galaxy into a black hole. How much comfort can you take in the fact that you know it doesn't diverge?

How would you write such a program?

    let replicate = http://prelude.dhall-lang.org/List/replicate
    in replicate 999999999999 Natural 1
(add additional nines if necessary)
Post reply on HN