12 ms·

The Dhall Configuration Language

232 points by bjourne 4y ago

junon 4y ago
> 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.
- alephaleph 4y ago
  How could they make the mistake obvious? It's a mistake in a string value!
  - bandyaboot 4y ago
    It had me confused too. I figured I was looking for a syntax error in the config format since it’s an introduction…to the config format.
  - TylerE 4y ago
    How about not making the very first thing on the page a confusing puzzle?
    - suby 4y ago
      They should at least reveal the answer somewhere immediately close by. I couldn't spot the error after a few minutes, came to the comments to find out what it was. Not a great introduction because you're asking someone to spot an error in something they don't know the syntax or ruleset for. The project looks cool though.
      - gre 4y ago
        Change the name from Bill to John/Jhon. That's more obvious than all the barcode characters next to each other.
- cbb330 4y ago
  This opinion is ironic because this is exactly what the author intended to describe -- the typo IS hard to find. The "Hello, World" example is nothing more than JSON, showing a string repeated 3 times. On the third time, "bill" is misspelled with "blil". The next tab shows how Dhall uses a variable definition to prevent this type of error.
  - junon 4y ago
    I took it to mean "can you find the syntax error". It wasn't clear they meant the text
    - CookieCrisp 4y ago
      Yeah, I eventually caught it but wished I hadn't wasted my time on it - seems like something they could better have shown with an animation
  - aendruk 4y ago
    I too spent the whole time scrutinizing the syntax and ignoring the values, since this is an intro to the language and not to Bill’s dotfiles. I was ultimately unable to deduce the presumed syntax error and independently came to the same misconclusion.
    - lilyball 4y ago
      It can't be a syntax error though as it evaluates successfully as demonstrated by the right-hand side.
      - aendruk 4y ago
        In general, if you think that someone’s claimed experience doesn’t make sense, you’re probably just missing information. On small viewports, the “right-hand side” is down page and off screen, and the instructions I’m following reference only tabs visible above.
  - corrral 4y ago
- clord 4y ago
  Meh, I think you're pointing out why doing this with a variable is better. In other words that mistake is the entire point of the example. Perhaps the definitions tab could make it more clear what the mistake was.
- CameronNemo 4y ago
  They are trying to tell a story about how Dhall helps you avoid hard to notice errors, but they aren't doing a great job. Would be cool if they had a three panel story: * using json with the typo * using dhall with the typo * using dhall with variables to avoid the typo Might be easier to understand.
- labster 4y ago
  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.
corrral 4y ago
{- You can optionally add types `x : T` means that `x` has type `T` -} let Config : Type = Config's type is Type? Clear as mud.
- edflsafoiewq 4y ago
  Config is a type, so it's type is Type.
  - corrral 4y ago
    Figured, but it's a pretty goofy way to introduce it after that comment. [EDIT] I mean, you can almost "who's on first?" this. "OK, what type do you want this to be?" "Type." "Yes, what type do you want it to be?" "Type." "Great, ok, yes, the type, what type is Config?" "Type." "WHAT IS THE NAME OF THE TYPE YOU WANT CONFIG TO BE???" "Type." flips desk
    - lilyball 4y ago
      Is it? My takeaway is "oh cool, first-class types". Experimenting with this, I can write the following: let ConfigOf : Type -> Type = \(type : Type) -> {- What happens if you add another field here? -} { home : type , privateKey : type , publicKey : type } let Config : Type = ConfigOf Text and the rest of the example still works and evaluates the same. Also in a later example it has the expression `generate 10 Config buildUser`, which also works because of first-class types. Instead of needing generics, you just take a type as a regular parameter.
6gvONxR4sf7o 4y ago
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.
- throwaway894345 4y ago
  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.
  - whateveracct 4y ago
    Totality checking like that in Idris is one nice example. That's kind of circular though - it isn't Turing complete because it has totality checking (i.e. you must prove the program terminates).
  - eru 4y ago
    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 not to eliminate long-running programs but to make them significantly less probable. In practice, you will discover that you will rarely author a configuration file that takes a long time to evaluate by accident. > For example, Dhall does not provide language support for recursion. If you try to define a recursive expression or function you will get a type error. Lists are the only recursive data structure and the only way to build or consume lists is through safe primitives guaranteed to terminate, like List/fold. This restrictive programming style keeps code simple and makes expensive code more obvious (both to the code author and reviewer).
    - throwaway894345 4y ago
      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.
cbb330 4y ago
I absolutely loved using this tool to generate many instances of Datadog resources in terraform json. Not only did it simplify a nasty mess of dynamic typed and schema-less bash/python/mako, it taught me a lot of functional programming paradigms along the way.
elikoga 4y ago
Tried to use it and it didn't fit my usecase: Recursive Types are a bit difficult Looks great otherwise
- ghostwriter 4y ago
  what kind of software configuration may require recursive types? I've never had to encode trees in my configs so far.
  - endgame 4y ago
    An explicit representation of JSON requires recursive types.
  - solatic 4y ago
    github.com/coralogix/dhall-concourse
svnpenn 4y ago
{ home = "/home/bill" , privateKey = "/home/bill/.ssh/id_ed25519" , publicKey = "/home/blil/.ssh/id_ed25519.pub" } This is the most awkward abuse of formatting I've seen in a long time. Just allow/require a final trailing comma, and this nonsense goes away
- sshine 4y ago
  This is a by-product of Dhall coming from the Haskell community where this formatting was preferred instead of final trailing commas. It has been internalised and was carried on. I say this as someone who looks at this code and thinks "This is totally fine." -- but I admit, I'm environmentally damaged.
  - eru 4y ago
    Yes. And, alas, you can't just allow a final trailing comma everywhere in Haskell. Eg ("Foo", 2,) is different from ("Foo", 2) in Haskell thanks to TupleSections. For innocent bystanders: in Haskell ("Foo", 2) is the tuple you'd expect it to be. But ("Foo", 2,) is a function that takes another argument and creates a three-tuple. A Python equivalent would be lambda x: ("Foo", 2, x)
- deleted 4y ago
  [deleted]
- chriswarbo 4y ago
  This style is common in Haskell, Nix and Dhall. It also sees more "mainstream" use, e.g. in SQL.
- layer8 4y ago
  Or allow a leading comma: { , home = "/home/bill" , privateKey = "/home/bill/.ssh/id_ed25519" , publicKey = "/home/blil/.ssh/id_ed25519.pub" } Or, to make it markdown-ish: { - home = "/home/bill" - privateKey = "/home/bill/.ssh/id_ed25519" - publicKey = "/home/blil/.ssh/id_ed25519.pub" } This is just to play with the idea that leading punctuation may be preferable because it all aligns in the same column.
notnmeyer 4y ago
this looks super useful, but its also horribly ugly.
- tmountain 4y ago
  I disagree regarding ugly, but it’s rooted in Haskell syntax fwiw.
abathur 4y ago
Previous thread w/ many comments: https://news.ycombinator.com/item?id=20355405 https://news.ycombinator.com/item?id=20355405 Another ~similar project not mentioned in that thread is https://ucg.marzhillstudios.com https://ucg.marzhillstudios.com
tr33house 4y ago
anyone using this for kubernetes config generation? What's been your experience?
- Sahbak 4y ago
  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.
  - tr33house 4y ago
    this is what I thought too. I've enjoyed working with helm and totally recommend it but was wondering if I'd missed something. A templating language and not an actual programming language seems to be the right balance for config
sshine 4y ago
Dhall is my favorite configuration language that I never get around to using. I manage DNS in Terraform, and since every Terraform provider uses different objects definitions, and every object definition is rather verbose, Dhall would be a way to specify my own DRY types and leave the provider-specific details in one place. Adding new DNS entries and moving several domains between providers would be a matter of changing fewer lines. Dhall also has Kubernetes bindings: https://github.com/dhall-lang/dhall-kubernetes https://github.com/dhall-lang/dhall-kubernetes Although I'm tempted to just stick to Helm here: even though it's less type-safe, Dhall's verbosity makes me reconsider. I'd like to hear if anyone has used dhall-kubernetes if they like it.
- CameronNemo 4y ago
  I use tanka/jsonnet and cringe everytime I read a helm chart. Type safety would be nice, but the k8s api can verify the validity on the server. https://tanka.dev/ https://tanka.dev/
  - leetrout 4y ago
    Tanka is what I want to use when the time comes. Are there any pitfalls you have learned to avoid?
    - mihaitodor 4y ago
      I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin https://github.com/kubernetes-monitoring/kubernetes-mixin LE: The "garbage collection" feature is very interesting, but I didn't get to experiment with it enough yet: https://tanka.dev/garbage-collection https://tanka.dev/garbage-collection
  - flas9sd 4y ago
    tanka helped me make peace with k8s (yaml) or at least made for a good learning environment for k8s than the other options. Wonder about other peoples experience or their rite of config tool passage
kukx 4y ago
I have been recently looking for a program that does a similar thing, ie simplifies creation of configs. And I did not find a suitable one by Googling. Then I realized the PHP is perfect for that and I already know it! The output of PHP does not have to be HTML or other web stuff, instead it can be a config file.
gurjeet 4y ago
Comparison with a related language (perhaps biased, since opinion is from creator of that language). "Comparisons between CUE, Jsonnet, Dhall, OPA, etc." https://github.com/cue-lang/cue/discussions/669 https://github.com/cue-lang/cue/discussions/669
_ofdw 4y ago
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.
- Ixiaus 4y ago
  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.
  - na85 4y ago
    I prefer to use multiple, smaller config files to keep them manageable.
- astrange 4y ago
  I think more programming power is useful in the service of stopping bugs; for instance, you could have a language where the part that "does stuff" isn't Turing complete, but the part that "stops incorrect stuff from happening" (the type system) is.
- benlivengood 4y ago
  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.
spawarotti 4y ago
Why not instead use one of the popular programming languages (C#, Java, ...), possibly with some dedicated library built on top of it? Also, reminds me of the Heptagon of Configuration [1]. [1] https://matt-rickard.com/heptagon-of-configuration https://matt-rickard.com/heptagon-of-configuration
wallyqs 4y ago
Dhall has a lot of really cool ideas, it would be great to have semantic integrity checks on imports in other languages too.
dcchambers 4y ago
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 from perfect, but it gets the job done pretty well and has been relatively easy for engineers across the company to pick up. That said, after a 3+ year journey, the shortfalls in our original design have become more noticeable and 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. Cue^2 is something I'm keeping an eye on these days as well. [1]: https://jsonnet.org/ https://jsonnet.org/ [2]: https://cuelang.org/ https://cuelang.org/
- mihaitodor 4y ago
  > using a more traditional language like Go to solve some of our configuration/deployment and data templating problems. Have you looked at https://github.com/kris-nova/naml https://github.com/kris-nova/naml ? :)
  - dcchambers 4y ago
    I had not seen that but it looks super interesting and potentially useful! Thanks for sharing!
- BFLpL0QNek 4y ago
  I like Dhall for what it gives you with type safer etc but the compile times are extremely slow on a large project and type signatures can get real long/hard. It is bit of a Dhall monolith though ;)
- vosper 4y ago
  > 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.
jonathanyc 4y ago
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.
- eru 4y ago
  Assigning functions to variables doesn't have to ruin your totality. But yeah, you'd need to carefully select your subset of the language that is both useful and total, and practical to implement.
- rtpg 4y ago
  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.
  - jonathanyc 4y ago
    Didn't know about Starlark, that is awesome.
fridental 4y ago
Why wouldn't you use Python as your configuration language?
- lytedev 4y ago
  I believe you may want a non-turing complete language for strict configuration. But sometimes, as you indicate, you want VERY dynamic configuration. But I would argue then that such logic goes in your application itself and is not in fact part of your configuration.
- jcookeak 4y ago
  For one thing, Dhall is not Turing complete. You can also freeze imports to prevent supply chain hacks, so it is much safer in theory. They have a great writeup on their safety here: https://docs.dhall-lang.org/discussions/Safety-guarantees.html https://docs.dhall-lang.org/discussions/Safety-guarantees.ht...
- chrisjharris 4y ago
  Most of the time with configuration files, you want to be able to do at least basic validation on the config without having to run the whole piece of software. Python has no native typing, so there's nothing to stop the user from creating a configuration file where, for example, they have set a field that is intended to specify a port number, as a string. This error will become obvious when you run the software (and it presumably fails some way in) but for some use cases this is too late. With dhall you can specify that the field for the port number needs to not just be an integer, but be a natural number, so you're able to catch plenty of config errors nice and early, and can go some way to validating the config in isolation from the software it's intended to be used for.
- Groxx 4y ago
  Have you seen Starlark? It's not too far from that, but safer in a number of ways: https://github.com/bazelbuild/starlark https://github.com/bazelbuild/starlark
  - q845712 4y ago
chubot 4y ago
Comparison of similar projects, including Dhall: https://github.com/oilshell/oil/wiki/Survey-of-Config-Languages https://github.com/oilshell/oil/wiki/Survey-of-Config-Langua...
lilyball 4y ago
I've always wanted an excuse to use this but never had a reason. The closest I come is using Nix, and I know there is a Dhall-to-Nix compiler, but Dhall can't represent everything possible in Nix I haven't seen any good reason to use it.
dang 4y ago
Related: Dhall: A Non-Repetitive Alternative to YAML - https://news.ycombinator.com/item?id=20355405 https://news.ycombinator.com/item?id=20355405 - July 2019 (177 comments)
avodonosov 4y ago
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.
- mixedCase 4y ago
  Strange choice for what? It's just one of the compile targets.
  - avodonosov 4y ago
    > 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.
mixedCase 4y ago
Dhall desperately needs a DefinitelyTyped-like repo with tooling support and it's bound to explode. It'd be just too good of a solution to ignore.
Blackthorn 4y ago
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.
- mdaniel 4y ago
  And yet, even if they did it right now, it'll be over there in the pile of "yet another configuration language" for the same reason we already have like 50 of them Damn network effect, ruining everything :-/
- __float 4y ago
  Can you say more about what GCL does better than all of the open source ones? Anecdotally, I've heard a lot of GCL horror stories, and many Xooglers have chosen to create things like Jsonnet or Skycfg (https://github.com/stripe/skycfg https://github.com/stripe/skycfg) instead.
  - Blackthorn 4y ago
    It creates nested data without looking like the end format of the data (why I really can't get into jsonnet), it's just obviously its own language but is pretty minimal. Despite the minimalism it is not necessarily simple. There are features like inheritance and late binding. They can be quite complicated, but the thing that really stands out about GCL is it's not complicated to use. The simple cases are easy, straightforward, and readable. The complicated cases are made possible. I've used it extensively to store and transform data that has to be manually edited by humans. It's a really great format because I can define all the translation rules which can get pretty complicated, but the complexity I expose to the humans who are writing the data is minimal. But if they need to do some transformations on the data or even just, like, string substitutions...the language is there and they can use it. That's what makes writing your data in a configuration language nice. (Honestly though I think jsonnet is at least vastly superior to skycfg and the whole starlark ecosystem. I swear I'm so sick of languages that intentionally look like Python without being actual Python!)
- 4y ago
rtpg 4y ago
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.
- Blackthorn 4y ago
  I feel increasing alone in this position but I absolutely hate those Python-like languages. They look like Python, and they occasionally act like Python. But occasionally they don't, and the mask of looking like Python obscures those times. Then you never really know which Python facilities you have and which ones you don't.
- thethethethe 4y ago
  Is skylark (now called starlark btw) general purpose? Its my understanding that its largely used for configuring bazel.
  - rtpg 4y ago
    https://github.com/google/starlark-go https://github.com/google/starlark-go
  - remram 4y ago
    It is used by other tools like Tilt https://tilt.dev/ https://tilt.dev/ (a Kubernetes dev tool)
la64710 4y ago
Whatever happened to Puppet, Ansible or Salt frameworks? They were the darling of the devops folks 7 years back.
- dvt 4y ago
  Or Terraform or Helm or ...
- tiew9Vii 4y ago
  They are different to Dhall. Puppet, Anisble and Salt are task runners. You give them configuration and they parse the configuration and then run tasks on a destination machine based on the configuration. Dhall is a tool to generate configuration such as json, yams, xml. It’s useful if you have *complex* configurations such as a AWS Cloudformation stack or Kubernetes yaml files.
  - la64710 4y ago
    Ah ok .. thanks for that details. Puppet was also called a configuration manager and it had the capability to generate configuration files of any format in a dynamic way (via support of variables, parameters etc).
- lmm 4y ago
  Kubernetes ate their lunch, mostly.
  - otabdeveloper4 4y ago
    No. Tools like Ansible are just wrappers around ssh when you need to run a command across many servers. They don't do anything k8s does.
    - slyall 4y ago
      I'd say partially right. 10 years ago people were running hundreds/thousands of VMs/Servers with full operating systems on them. They would often be long-lived and you needed puppet/ansible to update or run stuff on them. With kubernetes deployment and updating your app/data is all native. The servers/nodes often run some sort of cut down operating system and are immutable.
SomaticPirate 4y ago
Used this for a fairly complex, large project. It really is Haskell for configuration language and undoubtedly superior than YAML. But for my grug brain, function currying and the lack for loops made it hard. Functional languages continue to be a great place to steal from but pure functional requires warping your brain quite a bit. Maybe Tanka is more my style
- bbkane 4y ago
  Also look into Starlark or Cue
endgame 4y ago
I have been writing a fair amount of Dhall using autogenerated CloudFormation bindings ( https://github.com/jcouyang/dhall-aws-cloudformation/ https://github.com/jcouyang/dhall-aws-cloudformation/ ). It is a fantastic way to reduce boilerplate and factor out recurring blobs. My main frustration is that the type checker is not smart enough (or maybe the type system is undecidable?) - every time you want to use a polymorphic function, you must pass in the type parameters yourself (this is also true for empty lists and `None`). This makes simple FP idioms extremely noisy, to the point where you're better off writing longhand. In a language that's meant to be alleviating YAML/JSON boilerplate. It's still a massive improvement, but it could be so much better if the typechecker was smarter.
baby 4y ago
We use it for mina (https://github.com/MinaProtocol/mina https://github.com/MinaProtocol/mina). AMA
s-zeng 4y ago
Count me as another big Dhall fan -- Dhall was a huge improvement on our codebase compared to Helm for large Kubernetes deployments. Full disclosure: I maintain the [dhall](https://pypi.org/project/dhall/ https://pypi.org/project/dhall/) package on PyPI
hsn915 4y ago
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.
- jordanbeiber 4y ago
  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!
  - baby 4y ago
    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.
    - valenterry 4y ago
      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.
thayne 4y ago
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.
- ghostwriter 4y ago
  > 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. You can specify defaults for you record types via Type/default pattern https://github.com/Gabriella439/dhall-manual/blob/develop/manuscript/03-Defaults.md https://github.com/Gabriella439/dhall-manual/blob/develop/ma...
pharmakom 4y ago
Dhall needs to provide official bindings to all major platforms (these days that’s JS, Python, .NET, JVM). It looks like a really cool project but I don’t use Haskell or Ruby. Has the situation improved?
valenterry 4y ago
As much as I love Dhall, I think it's actually better to allow any turing complete programming language and require it to generate the config in a certain format (whatever it is, maybe even dhall). The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. If it takes too long then we stop it - the same we should do with a Dhall config as well, even if Dhall theoretically will finish in a finite amount of time. That way everyone can use their preferred language to describe and maintain the configuration. We just have to agree on the format that is being spit out at the end, such as json, yaml, dhall or even a proprietary format.
- eru 4y ago
  > The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. That's a very brittle restriction at best, and if implemented strictly on time, it's a very flaky on as well.
  - valenterry 4y ago
    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.
    - ghostwriter 4y ago
      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.
      - valenterry 4y ago
        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.
toastal 4y ago
I loved my experience with Dhall from the PureScript community. It prompted me to learn a lot more and I built some small libraries too. My experience was mostly positive. Supporting Unicode is the cherry on top. Of all my gripes, only two still stick in my mind: • No JavaScript implementation; I want to be able to use it more places, but I always end up having to convert it to JSON to use it • the built-in formatter is way too aggressive; I'm fond of the never-contract-only-expand formatters that don't pressure me to collapse things I don't want and the way it is isn’t to optimize Git diffs where conflicts can arise.
lucasdicioccio 4y ago
Dhall is advertised as a configuration language but you can do a tad more. I use it in my blog-engine to fit a use-case I found was poorly addressed by other approaches: small-cardinality datasets that benefit from type-checking and templating (e.g., list of notes, a photo gallery). I don't claim the idea is especially novel but I found the use case rare and interesting enough to write some explanations, design, and a demo here: https://lucasdicioccio.github.io/dhall-section-demo.html https://lucasdicioccio.github.io/dhall-section-demo.html
deleted 4y ago
[deleted]
norswap 4y ago
What are the advantages of this being its own language vs a DSL?
dustinevan 4y ago
Yikes! Don't do it folks! Business logic belongs in the apps, not in the config.

232 points by bjourne 4y ago

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

alephaleph 4y ago
How could they make the mistake obvious? It's a mistake in a string value!
- bandyaboot 4y ago
  It had me confused too. I figured I was looking for a syntax error in the config format since it’s an introduction…to the config format.
- TylerE 4y ago
  How about not making the very first thing on the page a confusing puzzle?
  - suby 4y ago
    They should at least reveal the answer somewhere immediately close by. I couldn't spot the error after a few minutes, came to the comments to find out what it was. Not a great introduction because you're asking someone to spot an error in something they don't know the syntax or ruleset for. The project looks cool though.
    - gre 4y ago
      Change the name from Bill to John/Jhon. That's more obvious than all the barcode characters next to each other.
cbb330 4y ago
This opinion is ironic because this is exactly what the author intended to describe -- the typo IS hard to find. The "Hello, World" example is nothing more than JSON, showing a string repeated 3 times. On the third time, "bill" is misspelled with "blil". The next tab shows how Dhall uses a variable definition to prevent this type of error.
- junon 4y ago
  I took it to mean "can you find the syntax error". It wasn't clear they meant the text
  - CookieCrisp 4y ago
    Yeah, I eventually caught it but wished I hadn't wasted my time on it - seems like something they could better have shown with an animation
- aendruk 4y ago
  I too spent the whole time scrutinizing the syntax and ignoring the values, since this is an intro to the language and not to Bill’s dotfiles. I was ultimately unable to deduce the presumed syntax error and independently came to the same misconclusion.
  - lilyball 4y ago
    It can't be a syntax error though as it evaluates successfully as demonstrated by the right-hand side.
    - aendruk 4y ago
      In general, if you think that someone’s claimed experience doesn’t make sense, you’re probably just missing information. On small viewports, the “right-hand side” is down page and off screen, and the instructions I’m following reference only tabs visible above.
- corrral 4y ago
clord 4y ago
Meh, I think you're pointing out why doing this with a variable is better. In other words that mistake is the entire point of the example. Perhaps the definitions tab could make it more clear what the mistake was.
CameronNemo 4y ago
They are trying to tell a story about how Dhall helps you avoid hard to notice errors, but they aren't doing a great job. Would be cool if they had a three panel story: * using json with the typo * using dhall with the typo * using dhall with variables to avoid the typo Might be easier to understand.
labster 4y ago
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.

corrral 4y ago

{- You can optionally add types `x : T` means that `x` has type `T` -} let Config : Type = Config's type is Type? Clear as mud.

edflsafoiewq 4y ago
Config is a type, so it's type is Type.
- corrral 4y ago
  Figured, but it's a pretty goofy way to introduce it after that comment. [EDIT] I mean, you can almost "who's on first?" this. "OK, what type do you want this to be?" "Type." "Yes, what type do you want it to be?" "Type." "Great, ok, yes, the type, what type is Config?" "Type." "WHAT IS THE NAME OF THE TYPE YOU WANT CONFIG TO BE???" "Type." flips desk
  - lilyball 4y ago
    Is it? My takeaway is "oh cool, first-class types". Experimenting with this, I can write the following: let ConfigOf : Type -> Type = \(type : Type) -> {- What happens if you add another field here? -} { home : type , privateKey : type , publicKey : type } let Config : Type = ConfigOf Text and the rest of the example still works and evaluates the same. Also in a later example it has the expression `generate 10 Config buildUser`, which also works because of first-class types. Instead of needing generics, you just take a type as a regular parameter.

6gvONxR4sf7o 4y ago

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.

throwaway894345 4y ago
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.
- whateveracct 4y ago
  Totality checking like that in Idris is one nice example. That's kind of circular though - it isn't Turing complete because it has totality checking (i.e. you must prove the program terminates).
- eru 4y ago
  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 not to eliminate long-running programs but to make them significantly less probable. In practice, you will discover that you will rarely author a configuration file that takes a long time to evaluate by accident. > For example, Dhall does not provide language support for recursion. If you try to define a recursive expression or function you will get a type error. Lists are the only recursive data structure and the only way to build or consume lists is through safe primitives guaranteed to terminate, like List/fold. This restrictive programming style keeps code simple and makes expensive code more obvious (both to the code author and reviewer).
  - throwaway894345 4y ago
    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.

cbb330 4y ago

I absolutely loved using this tool to generate many instances of Datadog resources in terraform json. Not only did it simplify a nasty mess of dynamic typed and schema-less bash/python/mako, it taught me a lot of functional programming paradigms along the way.

elikoga 4y ago

Tried to use it and it didn't fit my usecase: Recursive Types are a bit difficult Looks great otherwise

ghostwriter 4y ago
what kind of software configuration may require recursive types? I've never had to encode trees in my configs so far.
- endgame 4y ago
  An explicit representation of JSON requires recursive types.
- solatic 4y ago
  github.com/coralogix/dhall-concourse

svnpenn 4y ago

{ home = "/home/bill" , privateKey = "/home/bill/.ssh/id_ed25519" , publicKey = "/home/blil/.ssh/id_ed25519.pub" } This is the most awkward abuse of formatting I've seen in a long time. Just allow/require a final trailing comma, and this nonsense goes away

sshine 4y ago
This is a by-product of Dhall coming from the Haskell community where this formatting was preferred instead of final trailing commas. It has been internalised and was carried on. I say this as someone who looks at this code and thinks "This is totally fine." -- but I admit, I'm environmentally damaged.
- eru 4y ago
  Yes. And, alas, you can't just allow a final trailing comma everywhere in Haskell. Eg ("Foo", 2,) is different from ("Foo", 2) in Haskell thanks to TupleSections. For innocent bystanders: in Haskell ("Foo", 2) is the tuple you'd expect it to be. But ("Foo", 2,) is a function that takes another argument and creates a three-tuple. A Python equivalent would be lambda x: ("Foo", 2, x)
deleted 4y ago
[deleted]
chriswarbo 4y ago
This style is common in Haskell, Nix and Dhall. It also sees more "mainstream" use, e.g. in SQL.
layer8 4y ago
Or allow a leading comma: { , home = "/home/bill" , privateKey = "/home/bill/.ssh/id_ed25519" , publicKey = "/home/blil/.ssh/id_ed25519.pub" } Or, to make it markdown-ish: { - home = "/home/bill" - privateKey = "/home/bill/.ssh/id_ed25519" - publicKey = "/home/blil/.ssh/id_ed25519.pub" } This is just to play with the idea that leading punctuation may be preferable because it all aligns in the same column.

notnmeyer 4y ago

this looks super useful, but its also horribly ugly.

tmountain 4y ago
I disagree regarding ugly, but it’s rooted in Haskell syntax fwiw.

abathur 4y ago

Previous thread w/ many comments: https://news.ycombinator.com/item?id=20355405 https://news.ycombinator.com/item?id=20355405 Another ~similar project not mentioned in that thread is https://ucg.marzhillstudios.com https://ucg.marzhillstudios.com

tr33house 4y ago

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

Sahbak 4y ago
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.
- tr33house 4y ago
  this is what I thought too. I've enjoyed working with helm and totally recommend it but was wondering if I'd missed something. A templating language and not an actual programming language seems to be the right balance for config

sshine 4y ago

Dhall is my favorite configuration language that I never get around to using. I manage DNS in Terraform, and since every Terraform provider uses different objects definitions, and every object definition is rather verbose, Dhall would be a way to specify my own DRY types and leave the provider-specific details in one place. Adding new DNS entries and moving several domains between providers would be a matter of changing fewer lines. Dhall also has Kubernetes bindings: https://github.com/dhall-lang/dhall-kubernetes https://github.com/dhall-lang/dhall-kubernetes Although I'm tempted to just stick to Helm here: even though it's less type-safe, Dhall's verbosity makes me reconsider. I'd like to hear if anyone has used dhall-kubernetes if they like it.

CameronNemo 4y ago
I use tanka/jsonnet and cringe everytime I read a helm chart. Type safety would be nice, but the k8s api can verify the validity on the server. https://tanka.dev/ https://tanka.dev/
- leetrout 4y ago
  Tanka is what I want to use when the time comes. Are there any pitfalls you have learned to avoid?
  - mihaitodor 4y ago
    I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin https://github.com/kubernetes-monitoring/kubernetes-mixin LE: The "garbage collection" feature is very interesting, but I didn't get to experiment with it enough yet: https://tanka.dev/garbage-collection https://tanka.dev/garbage-collection
- flas9sd 4y ago
  tanka helped me make peace with k8s (yaml) or at least made for a good learning environment for k8s than the other options. Wonder about other peoples experience or their rite of config tool passage

kukx 4y ago

I have been recently looking for a program that does a similar thing, ie simplifies creation of configs. And I did not find a suitable one by Googling. Then I realized the PHP is perfect for that and I already know it! The output of PHP does not have to be HTML or other web stuff, instead it can be a config file.

gurjeet 4y ago

Comparison with a related language (perhaps biased, since opinion is from creator of that language). "Comparisons between CUE, Jsonnet, Dhall, OPA, etc." https://github.com/cue-lang/cue/discussions/669 https://github.com/cue-lang/cue/discussions/669

_ofdw 4y ago

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.

Ixiaus 4y ago
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.
- na85 4y ago
  I prefer to use multiple, smaller config files to keep them manageable.
astrange 4y ago
I think more programming power is useful in the service of stopping bugs; for instance, you could have a language where the part that "does stuff" isn't Turing complete, but the part that "stops incorrect stuff from happening" (the type system) is.
benlivengood 4y ago
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.

spawarotti 4y ago

Why not instead use one of the popular programming languages (C#, Java, ...), possibly with some dedicated library built on top of it? Also, reminds me of the Heptagon of Configuration [1]. [1] https://matt-rickard.com/heptagon-of-configuration https://matt-rickard.com/heptagon-of-configuration

wallyqs 4y ago

Dhall has a lot of really cool ideas, it would be great to have semantic integrity checks on imports in other languages too.

dcchambers 4y ago

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 from perfect, but it gets the job done pretty well and has been relatively easy for engineers across the company to pick up. That said, after a 3+ year journey, the shortfalls in our original design have become more noticeable and 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. Cue^2 is something I'm keeping an eye on these days as well. [1]: https://jsonnet.org/ https://jsonnet.org/ [2]: https://cuelang.org/ https://cuelang.org/

mihaitodor 4y ago
> using a more traditional language like Go to solve some of our configuration/deployment and data templating problems. Have you looked at https://github.com/kris-nova/naml https://github.com/kris-nova/naml ? :)
- dcchambers 4y ago
  I had not seen that but it looks super interesting and potentially useful! Thanks for sharing!
BFLpL0QNek 4y ago
I like Dhall for what it gives you with type safer etc but the compile times are extremely slow on a large project and type signatures can get real long/hard. It is bit of a Dhall monolith though ;)
vosper 4y ago
> 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.

jonathanyc 4y ago

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.

eru 4y ago
Assigning functions to variables doesn't have to ruin your totality. But yeah, you'd need to carefully select your subset of the language that is both useful and total, and practical to implement.
rtpg 4y ago
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.
- jonathanyc 4y ago
  Didn't know about Starlark, that is awesome.

fridental 4y ago

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

lytedev 4y ago
I believe you may want a non-turing complete language for strict configuration. But sometimes, as you indicate, you want VERY dynamic configuration. But I would argue then that such logic goes in your application itself and is not in fact part of your configuration.
jcookeak 4y ago
For one thing, Dhall is not Turing complete. You can also freeze imports to prevent supply chain hacks, so it is much safer in theory. They have a great writeup on their safety here: https://docs.dhall-lang.org/discussions/Safety-guarantees.html https://docs.dhall-lang.org/discussions/Safety-guarantees.ht...
chrisjharris 4y ago
Most of the time with configuration files, you want to be able to do at least basic validation on the config without having to run the whole piece of software. Python has no native typing, so there's nothing to stop the user from creating a configuration file where, for example, they have set a field that is intended to specify a port number, as a string. This error will become obvious when you run the software (and it presumably fails some way in) but for some use cases this is too late. With dhall you can specify that the field for the port number needs to not just be an integer, but be a natural number, so you're able to catch plenty of config errors nice and early, and can go some way to validating the config in isolation from the software it's intended to be used for.
Groxx 4y ago
Have you seen Starlark? It's not too far from that, but safer in a number of ways: https://github.com/bazelbuild/starlark https://github.com/bazelbuild/starlark
- q845712 4y ago

chubot 4y ago

Comparison of similar projects, including Dhall: https://github.com/oilshell/oil/wiki/Survey-of-Config-Languages https://github.com/oilshell/oil/wiki/Survey-of-Config-Langua...

lilyball 4y ago

I've always wanted an excuse to use this but never had a reason. The closest I come is using Nix, and I know there is a Dhall-to-Nix compiler, but Dhall can't represent everything possible in Nix I haven't seen any good reason to use it.

dang 4y ago

Related: Dhall: A Non-Repetitive Alternative to YAML - https://news.ycombinator.com/item?id=20355405 https://news.ycombinator.com/item?id=20355405 - July 2019 (177 comments)

avodonosov 4y ago

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.

mixedCase 4y ago
Strange choice for what? It's just one of the compile targets.
- avodonosov 4y ago
  > 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.

mixedCase 4y ago

Dhall desperately needs a DefinitelyTyped-like repo with tooling support and it's bound to explode. It'd be just too good of a solution to ignore.

Blackthorn 4y ago

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.

mdaniel 4y ago
And yet, even if they did it right now, it'll be over there in the pile of "yet another configuration language" for the same reason we already have like 50 of them Damn network effect, ruining everything :-/
__float 4y ago
Can you say more about what GCL does better than all of the open source ones? Anecdotally, I've heard a lot of GCL horror stories, and many Xooglers have chosen to create things like Jsonnet or Skycfg (https://github.com/stripe/skycfg https://github.com/stripe/skycfg) instead.
- Blackthorn 4y ago
  It creates nested data without looking like the end format of the data (why I really can't get into jsonnet), it's just obviously its own language but is pretty minimal. Despite the minimalism it is not necessarily simple. There are features like inheritance and late binding. They can be quite complicated, but the thing that really stands out about GCL is it's not complicated to use. The simple cases are easy, straightforward, and readable. The complicated cases are made possible. I've used it extensively to store and transform data that has to be manually edited by humans. It's a really great format because I can define all the translation rules which can get pretty complicated, but the complexity I expose to the humans who are writing the data is minimal. But if they need to do some transformations on the data or even just, like, string substitutions...the language is there and they can use it. That's what makes writing your data in a configuration language nice. (Honestly though I think jsonnet is at least vastly superior to skycfg and the whole starlark ecosystem. I swear I'm so sick of languages that intentionally look like Python without being actual Python!)
4y ago

rtpg 4y ago

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.

Blackthorn 4y ago
I feel increasing alone in this position but I absolutely hate those Python-like languages. They look like Python, and they occasionally act like Python. But occasionally they don't, and the mask of looking like Python obscures those times. Then you never really know which Python facilities you have and which ones you don't.
thethethethe 4y ago
Is skylark (now called starlark btw) general purpose? Its my understanding that its largely used for configuring bazel.
- rtpg 4y ago
  https://github.com/google/starlark-go https://github.com/google/starlark-go
- remram 4y ago
  It is used by other tools like Tilt https://tilt.dev/ https://tilt.dev/ (a Kubernetes dev tool)

la64710 4y ago

Whatever happened to Puppet, Ansible or Salt frameworks? They were the darling of the devops folks 7 years back.

dvt 4y ago
Or Terraform or Helm or ...
tiew9Vii 4y ago
They are different to Dhall. Puppet, Anisble and Salt are task runners. You give them configuration and they parse the configuration and then run tasks on a destination machine based on the configuration. Dhall is a tool to generate configuration such as json, yams, xml. It’s useful if you have *complex* configurations such as a AWS Cloudformation stack or Kubernetes yaml files.
- la64710 4y ago
  Ah ok .. thanks for that details. Puppet was also called a configuration manager and it had the capability to generate configuration files of any format in a dynamic way (via support of variables, parameters etc).
lmm 4y ago
Kubernetes ate their lunch, mostly.
- otabdeveloper4 4y ago
  No. Tools like Ansible are just wrappers around ssh when you need to run a command across many servers. They don't do anything k8s does.
  - slyall 4y ago
    I'd say partially right. 10 years ago people were running hundreds/thousands of VMs/Servers with full operating systems on them. They would often be long-lived and you needed puppet/ansible to update or run stuff on them. With kubernetes deployment and updating your app/data is all native. The servers/nodes often run some sort of cut down operating system and are immutable.

SomaticPirate 4y ago

Used this for a fairly complex, large project. It really is Haskell for configuration language and undoubtedly superior than YAML. But for my grug brain, function currying and the lack for loops made it hard. Functional languages continue to be a great place to steal from but pure functional requires warping your brain quite a bit. Maybe Tanka is more my style

bbkane 4y ago
Also look into Starlark or Cue

endgame 4y ago

I have been writing a fair amount of Dhall using autogenerated CloudFormation bindings ( https://github.com/jcouyang/dhall-aws-cloudformation/ https://github.com/jcouyang/dhall-aws-cloudformation/ ). It is a fantastic way to reduce boilerplate and factor out recurring blobs. My main frustration is that the type checker is not smart enough (or maybe the type system is undecidable?) - every time you want to use a polymorphic function, you must pass in the type parameters yourself (this is also true for empty lists and `None`). This makes simple FP idioms extremely noisy, to the point where you're better off writing longhand. In a language that's meant to be alleviating YAML/JSON boilerplate. It's still a massive improvement, but it could be so much better if the typechecker was smarter.

baby 4y ago

We use it for mina (https://github.com/MinaProtocol/mina https://github.com/MinaProtocol/mina). AMA

s-zeng 4y ago

Count me as another big Dhall fan -- Dhall was a huge improvement on our codebase compared to Helm for large Kubernetes deployments. Full disclosure: I maintain the [dhall](https://pypi.org/project/dhall/ https://pypi.org/project/dhall/) package on PyPI

hsn915 4y ago

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.

jordanbeiber 4y ago
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!
- baby 4y ago
  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.
  - valenterry 4y ago
    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.

thayne 4y ago

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.

ghostwriter 4y ago
> 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. You can specify defaults for you record types via Type/default pattern https://github.com/Gabriella439/dhall-manual/blob/develop/manuscript/03-Defaults.md https://github.com/Gabriella439/dhall-manual/blob/develop/ma...

pharmakom 4y ago

Dhall needs to provide official bindings to all major platforms (these days that’s JS, Python, .NET, JVM). It looks like a really cool project but I don’t use Haskell or Ruby. Has the situation improved?

valenterry 4y ago

As much as I love Dhall, I think it's actually better to allow any turing complete programming language and require it to generate the config in a certain format (whatever it is, maybe even dhall). The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. If it takes too long then we stop it - the same we should do with a Dhall config as well, even if Dhall theoretically will finish in a finite amount of time. That way everyone can use their preferred language to describe and maintain the configuration. We just have to agree on the format that is being spit out at the end, such as json, yaml, dhall or even a proprietary format.

eru 4y ago
> The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. That's a very brittle restriction at best, and if implemented strictly on time, it's a very flaky on as well.
- valenterry 4y ago
  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.
  - ghostwriter 4y ago
    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.
    - valenterry 4y ago
      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.

toastal 4y ago

I loved my experience with Dhall from the PureScript community. It prompted me to learn a lot more and I built some small libraries too. My experience was mostly positive. Supporting Unicode is the cherry on top. Of all my gripes, only two still stick in my mind: • No JavaScript implementation; I want to be able to use it more places, but I always end up having to convert it to JSON to use it • the built-in formatter is way too aggressive; I'm fond of the never-contract-only-expand formatters that don't pressure me to collapse things I don't want and the way it is isn’t to optimize Git diffs where conflicts can arise.

lucasdicioccio 4y ago

Dhall is advertised as a configuration language but you can do a tad more. I use it in my blog-engine to fit a use-case I found was poorly addressed by other approaches: small-cardinality datasets that benefit from type-checking and templating (e.g., list of notes, a photo gallery). I don't claim the idea is especially novel but I found the use case rare and interesting enough to write some explanations, design, and a demo here: https://lucasdicioccio.github.io/dhall-section-demo.html https://lucasdicioccio.github.io/dhall-section-demo.html

deleted 4y ago

[deleted]

norswap 4y ago

What are the advantages of this being its own language vs a DSL?

dustinevan 4y ago

Yikes! Don't do it folks! Business logic belongs in the apps, not in the config.