16 ms·

Dhall: A Non-Repetitive Alternative to YAML

• nhooyr 7y ago
  What's with the commas at the start of lines?
  • edoceo 7y ago
    Makes it easier when commenting out. Use this trick for SQL and JS too (to prevent trailing comma issue)
    • dymk 7y ago
      I don't get why you'd build a language in 2019 which disallows a trailing comma in lists.
      • andybak 7y ago
        Yep. The solution to comma issues isn't to put every single one in a place nobody usually puts them - it's to be more forgiving about allowing the occasional trailing one.
        • twblalock 7y ago
          The solution is to get rid of them. They are not necessary.
          • Gabriel439 7y ago
            Author here: commas are necessary to separate list elements in any language where function application uses whitespace (i.e. Haskell-style function application). If you're not familiar with the syntax, an expression like `f x y z` is a function `f` applied to three arguments (`x`, `y`, and `z`), analogous to `f(x, y, z)` in a more traditional language. Nix made this mistake of using whitespace to separate list elements AND using whitespace to separate a function from its argument and it is a very common pain point for new users, because they will write something like this: [ theFunction theFunction'sArgument ] ... thinking it will be parsed as: [ (theFunction theFunction'sArgument) ] ... but it actually gets parsed as a list with two elements, leading to a bizarre type error.
      • nikolay 7y ago
        There's absolutely no need for commas in a configuration language, in my opinion.
      • j88439h84 7y ago
        Alternatively it could allow leading commas.
      • keymone 7y ago
        On the other hand - why would you build a language where commas aren’t treated as whitespace?
        • dymk 7y ago
          You could absolutely do this as well. I'm just taking issue with a language that constrains you in such a way that you have to put the commas at the beginning of the list elements, so it plays nicely with {comments, source control blame}.
      • Jeff_Brown 7y ago
        Dhall does not disallow trailing commas, nor require leading ones.
  • jbaum98 7y ago
    This is a common convention in some languages, most often functional languages in my experience. I associate it most with OCaml. So it's not so surprising to see it here, seeing as Dhall is written in Haskell.
  • mitchtbaum 7y ago
    Better Syntax for Lists, Records (and Unions) #66 https://github.com/dhall-lang/dhall-lang/issues/66 https://github.com/dhall-lang/dhall-lang/issues/66
• nikolay 7y ago
  Dhall keeps popping up on HN. Here what I don't like about it: - Why use '=' instead of ':' for attributes? If you used ':', then '=' could be variable assignment and eliminate the need for 'let'. - Why is there a need for commas? - Why quote via ticks?! Gee! - What's with the '{-' and '-}' for comments?! It's like its author decided to differ at any price! In general, good ideas, but it's too weird and unnecessarily deviates from common syntax.
  • duijf 7y ago
    Dhall heavily borrows both ideas and syntax from the ML family of languages. E.g. Haskell, OCaml, Elm, Purescript Colons are used for type signatures. Commas are presumably required because you can have multi line and nested records. (don't quote me on this, not a parser expert) The comment syntax is from Haskell. Not saying this syntax is familiar to everyone, but it is familiar to some. The lineage of the syntax might help you understand where the language is coming from
    • dymk 7y ago
      Weird that it's billed as an alternative to YAML, but effectively has zero roots or influence from YAML. Looks more like an alternative to... whatever configuration language is popular in ML language projects?
      • londt8 7y ago
        Its more like an alternative to scripts generating configuration from templates. they claim that this is better because you cant for example write an infinite loop ruining the script.
        • owl57 7y ago
          Is it a real problem though? If your config generator is complex enough to hide an infinite loop, you probably should be relieved every time it fails obviously and doesn't generate wrong config instead.
      • 7y ago
• NuSkooler 7y ago
  Still much prefer HJSON (http://hjson.org/ http://hjson.org/) for stuff that people might need to touch. If it's truly for end-users (read: non-admin/dev types), you probably shouldn't have them touching configuration files _at all_.
  • tobr 7y ago
    How is this at all related to Dhall? It looks like a completely different thing with a completely different purpose.
    • NuSkooler 7y ago
      They are both text based configuration file formats made to be easier for humans to interact with, so I'm not sure what you're confused about?
      • tobr 7y ago
        That’s about the least interesting thing about Dhall. (It’s weird that they tout it prominently on the homepage.) There are so many flavors of syntax sugar for JSON, Dhall is a completely different beast.
        • mcphage 7y ago
          You might want to ask the HN admins to rename the title for this post, then.
          • tobr 7y ago
            It looks fine to me. Reducing repetition is precisely the type of thing Dhall’s features should be useful for.
  • epage 7y ago
    Don't fully remember why I prefer json5 to hjson but at a quick glance, bare values is one. Bare values are ripe for someone entering in a string and accidentally getting a bool or number instead.
• andybak 7y ago
  Immediate response? I hate commas at the start of lines and I would prefer not to have curly braces in a human editable/readable format. Neither reason is terribly rational but my first impressions weren't great.
  • piotrkubisa 7y ago
    It looks that Dhall has been inspired of the Elm language [0] and it's formatter. [0]: https://guide.elm-lang.org/ https://guide.elm-lang.org/
    • bvaldivielso 7y ago
      It's a common practice in the Haskell community. Knowing where the creator of dhall comes from I would say that that's the source of inspiration
      • Gabriel439 7y ago
        Author here: the syntax is inspired by all three of Haskell/PureScript/Elm
  • Jeff_Brown 7y ago
    > commas at the start of lines are not a requirement.
    • anentropic 7y ago
      OTOH I would guess it doesn't allow a trailing comma (same problem as JSON...) so you end up with weird ugly formatting conventions
      • Jeff_Brown 7y ago
        No, you can use trailing commas if you want.
      • singpolyma3 7y ago
• isoprophlex 7y ago
  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 like I'm throwing sourness around, but I just don't see the niche for this, except inventing a new thing for the joy of it?
  • afiori 7y ago
    One reason is that "configuration language" is an extremely wide topic. Some configs use yaml to encode bash scripts for example. Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Honestly it is the reason I like TOML, with the exception of the date data type it cleanly maps to json (which everyone agrees it is a good enough serialization format) and it is specifically focused on human friendliness (except uniform lists) and readability As an underappreciated feature, the ability to have scoped keyvalues allow to define nested table with flat statements.
    • isoprophlex 7y ago
      > Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Okay thanks, that's a good one. Readability might be a big deal.
  • zeliard 7y ago
    >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? Well, for same reason, say, why people would use a javascript framework to build a webapp over vanilla js. Both could do the job, and for simple cases there's little reason to go with a framework resp. specialized config language. But as your app/config gets larger and more complex, using a framework resp. config language would tend to get the job done more efficiently by providing you structure and toolbox with solutions to common pain points. Config generators themselves tend to be a rather heavyweight all-or-nothing solution which leads people to compromise on some adhoc middle-ground solutions like YAML with jinja templates with unclear evaluation semantics. A good config language designed from the ground up can be so much better than this unholy yaml/jinja mess! Finally, one of the key selling points of specifically Dhall is type checking. Implementing that in config generators in a generic untyped scripting language would be a nontrivial amount of boilerplate, and boilerplate elimination is what config languages are all about.
• tobr 7y ago
  So far, only comments complaining about syntax. You can do better, HN!
  • nikolay 7y ago
    Yeah, because that's what most configuration languages differ in.
    • kccqzy 7y ago
      And yet, in focusing on the syntax, you missed the biggest difference between Dhall and other configuration languages: safe, termination-guaranteed non-Turing-complete computation.
      • nikolay 7y ago
        How is it better than Jsonnet or Starlark?
        • tobr 7y ago
          Why are you implying that kccqzy thinks Dhall is better than Jsonnet or Starlark?
          • nikolay 7y ago
            A new project should be better than the old ones. Otherwise, what's the point?
        • mbrock 7y ago
          static type system
          • nikolay 7y ago
            True. But isn't this also accomplished when pairing JSON with JSON Schema?
• zeliard 7y ago
  Couple of contenders: - Jsonnet (https://jsonnet.org/ https://jsonnet.org/) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL) - Cue (https://github.com/cuelang/cue https://github.com/cuelang/cue) - a more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification. Great thread comparing them against each other by the authors of both: https://github.com/cuelang/cue/issues/33 https://github.com/cuelang/cue/issues/33 Cue seems kind of similar to Dhall on first sight, but I haven't used either enough for an informed opinion yet.
  • Ericson2314 7y ago
    Cue is a bit too cute trying to combine the subtyping and inhabitance relations into one.
    • skybrian 7y ago
      What problems do you see?
  • dharmab 7y ago
    We tried to introduce Jsonnet at our org. It failed miserably because ops kept mistaking the name for JSON which they hated. (International multilingual team). It was a real shame because ops then implemented some features of Jsonnet via scripts to to parse and merge YAML. What was 0 LOC in Jsonnet is now about 300 LOC plus custom CI checkers, all because of a marketing problem.
    • Fnoord 7y ago
      If I go to the mentioned Jsonnet homepage it says "A simple extension of JSON". The graphic explains its relation to JSON. The example looks awfully similar to JSON. What I don't understand is the following: config files are read by text editors, and in the end, by human beings. Because of the latter they should have certain traits. We must agree on the importance of these traits before we can settle on a standard. For me, important features are that they must be readable, and easily editable. They must be readable with a certain text editor (vi) for backwards compatibility. So that means it shouldn't require syntax highlighting or schema. Well, these 2 simple requirements of mine rule out anything remotely resembling JSON. It just appears to me that JSON is for JavaScript developers, YAML for Python developers, and Dhall for ML (the whole family I suppose, not just Haskell) developers. Well then if we're going that route then perhaps all we need is some kind of glue between text config and binary config (which reminds me of Systemd...). Ie. that it accepts multiple config file formats.
• choeger 7y ago
  Hmm... So the authors claim that their language is guaranteed to terminate for all well-typed programs. That is actually a nice spot for configuration languages. Yet, I wonder how a) they guarantee it, as I have seen no obvious link to the language's semantics b) useful this is in practice. Nevertheless, very nice approach, indeed.
  • yunyu 7y ago
    There is no support for recursion and the usual workarounds don't apply, so the language is not Turing complete: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees#turing-completeness https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant...
  • codebje 7y ago
    Build systems tend to get very complex Turing complete scripts, such as gradle for Java or Make for C. Having something almost as powerful but reducible to a normal form is very helpful for CASE tools.
    • skybrian 7y ago
      Banning Turing completeness doesn't give you the property you want, though. Knowing that reducing to a normal form eventually terminates if you wait a million years may be something mathematicians care about, but isn't of practical use. What matters is that you can analyze the code quickly. To find that out, one way is to try it and kill the process if it takes too long. Or perhaps better would be to come up with a portable definition of what "takes too long" means that you can put in a presubmit check. Something like "running out of gas" in Ethereum.
• dang 7y ago
  Thread from 2018: https://news.ycombinator.com/item?id=17523623 https://news.ycombinator.com/item?id=17523623 2017: https://news.ycombinator.com/item?id=15185015 https://news.ycombinator.com/item?id=15185015 2016: https://news.ycombinator.com/item?id=13109672 https://news.ycombinator.com/item?id=13109672
• adev_ 7y ago
  For a pragmatic, really readable configuration file format, TOML never disappointed me ( https://github.com/toml-lang/toml#user-content-local-date https://github.com/toml-lang/toml#user-content-local-date ). - This is human readable contrary to the JSON family and its {} abuses. - It is not space / ident base contrary to YAML that becomes very quickly a mess to write and a mess to parse.
  • epage 7y ago
    As a fan of TOML, I want to be clear on the downsides. TOML is good for data layed out with TOML. Representing arbitrary nested arrays and tables gets messy. Also, the constraint on homogenous shallow types has impacted me in some cases. Originally, I was all on board. Arrays should be homogenous. The problem is logically homogenous vs syntactically homogenous. Cargo uses tables to declare dependencies. The values are logically homogenous, they are declarations. Synatictically, some values are strings while the rest are sub-tables. The string is just shorthand for a table though. This feature can't be implemented in arrays like it can with tables.
  • nikolay 7y ago
    TOML is almost perfect. The only things I don't like are the need for commas and the double brackets.
    • smitty1e 7y ago
      Perfection is a bugaboo. Give me 95%, minor inconveniences, and declare vict'ry, say I.
• mitchtbaum 7y ago
  This looks very useful.
  • mitchtbaum 7y ago
    looking further, it seems that aside from repetitiveness, safety is the main focus: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees#types https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant... which in Rust, we're solving this via SANE and SCL: https://gitlab.com/bloom42/sane-rs https://gitlab.com/bloom42/sane-rs https://github.com/keats/scl https://github.com/keats/scl I'm not sure how much need there is for an additional programming layer, especially within config (the part of a program with the simplest syntactic requirements). for my projects where "ahead-of-time validation" is needed, we're currently using SCL's parser for safety guarantees: https://github.com/foundpatterns/contentdb https://github.com/foundpatterns/contentdb https://github.com/foundpatterns/lighttouch/blob/d7ada4576a6f8865a625f6ffa18452ec90353db5/loaders/models.lua https://github.com/foundpatterns/lighttouch/blob/d7ada4576a6... https://github.com/foundpatterns/torchbear/blob/4dd2b9ea76ba0911d586ec5a0276f53053bd9738/src/bindings/text/scl.rs https://github.com/foundpatterns/torchbear/blob/4dd2b9ea76ba...
    • ff_ 7y ago
      From a cursory look to SANE and SCL it looks like Dhall still offers some more: - functions - a powerful typesystem - remote (HTTP) imports with sha256 checksums
• mitchtbaum 7y ago
  Rust bindings tracking issue https://github.com/Nadrieril/dhall-rust/issues/77 https://github.com/Nadrieril/dhall-rust/issues/77
• cryptonector 7y ago
  If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete. Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for configuration. Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means that I can use JSON, TOML-style, and other ways of expressing complex data, including combinations of them, all with "interpolation" (not quite) and complex computation being available. [0] https://stedolan.github.io/jq/
  • Quekid5 7y ago
    One valuable point of Dhall is that it is programmable (yet not TC) in such a way to that you can e.g. describe a whole system entirely in Dhall and then (in Dhall!) derive whatever further configurations (plural!) you need from that. This is much more feasible than in e.g. YAML because Dhall is strongly typed. So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with all their boilerplate), derive DNS config files, etc. etc. all from a single strongly typed description.
    • Boulth 7y ago
      It goes even further: because Dhall supports functions one can write a function that will migrate old configs to new format. Migration function can also be type checked (it must accept old config format and emit new one). Of course all of this without TC.
    • cryptonector 7y ago
      I mean, jq is a powerful programming language. Did you look at the link I posted?
      • jessaustin 7y ago
        Well, you did format it so that it's not clickable...
      • 7y ago
• iamaelephant 7y ago
  https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
• KirinDave 7y ago
  Dhall is fantastic and I try to encourage everyone in tech I meet try it.
  • GordonS 7y ago
    OK, why?
    • KirinDave 7y ago
      Because it is a good mix of features, syntax, execution speed and correctness. Of course. Didn't you read the article?
      • GordonS 7y ago
        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.
        • KirinDave 7y ago
          > I did, and it's bad form to suggest otherwise. If you say so. But... I said I think the features are good and you ask "why?" I could relist the features, but that's a waste of time. As I said, I think the combination is a good combination. In a world where people try to encode loops in YAML or JSON, even small improvements are better and Dhall is a large improvement. > I was asking about your personal opinion, since you said it was great but didn't give any info as to why. I don't really get what you're asking. I said I think the combination of features is good. I don't need to describe the features. The reason I like them is probably related to neurochemistry? Are you asking for a deep dive on how Dhall compares to alternatives?
          • GordonS 7y ago
            Then I apologise; because you posted I assumed you were happy to or wanted to engage in discourse, maybe highlight your favourite features, possibly debate the value it bring, that kind of thing, but I see my mistake now.
• oalessandr 7y ago
  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 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 abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear) I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.
  • amluto 7y ago
    > 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 the same output unless I explicitly change an input. Pulling a prelude off of github does misses several of these requirements. (Having your config file fail to parse if your network is down is bad, bad news if that config is needed to bring your network up. It’s also bad news if a parsing failure due to a transient network issue leaves your system in a state where it won’t quickly recover if the network comes back.)
    • oalessandr 7y ago
      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/standard/imports.md https://github.com/dhall-lang/dhall-lang/blob/master/standar...
• deleted 7y ago
  [deleted]
• arkh 7y ago
  let input = { relative = "daughter" , movies = [ "Boss Baby", "Frozen", "Moana" ] } We don't frequent the same kind of "non-technical users" I guess.
• desc 7y ago
  Programmable configuration is always and without exception a monumentally stupid idea. Programmatic generation of static configuration files can be very useful. Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned. If you need to write a program to configure your program, you're probably doing it wrong.
  • nine_k 7y ago
    Configs allow to add flexibility past compile time, often dynamically at runtime.
    • desc 7y ago
      Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated. Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple. Executable config, run during startup or, worse, on each request? NO. [edit] I think that's the main disconnect here: 'past compile time'. The whole point of testing, strong type systems, etc is to lock down the set of states the system can be in. If your configuration is so 'dynamic' you are essentially abandoning all those benefits and saying 'yeah, do what you like to our live servers'. In short, configuration which is that powerful is indistinguishable from running untested code in production.
      • jose_zap 7y ago
        Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.
        • desc 7y ago
          Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration. We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so it got fudged in deployment instead of being fixed in application design.
• markandrewj 7y ago
  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 think that it is cleaner to separate logic and data, instead of creating a tight coupling. I don't read many people making comments from this perspective though. I am not trying to say we can't do better then YAML/JSON, I am just trying to offer some food for thought. I tend to view JSON/YAML as a data exchange format, and not a programming language, so I am not bothered by the lack of Turing completeness.
  • nine_k 7y ago
    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.
    • dharmab 7y ago
      Previously in my career I've abused Jinja templating to build "scripts" out of Ansible and SaltStack YAML. It solved business problems effectively but I'm sure when I left that role I passed on a big plate of spaghetti to my successor with minimal automated tests. If it depends on conditional logic or iteration, it probably belongs in a proper programming language with a linter, type checkers, debugger and unit test framework.
      • eropple 7y ago
        This is one of the reasons why, coming from a background of writing Chef and writing exhaustive testing around my configuration management, I've never been able to deal with Ansible without grinding my teeth. Or, for that matter, Terraform; HCL is godawful and trying to write it in JSON is a sucker's bet, too. With the move towards more containerized systems I don't write Chef much anymore (thankfully), but Terraform has become ever more of a boil on my rear end. Fortunately there's also Pulumi now and writing this stuff in TypeScript is a lot faster and feels really good.
• amingilani 7y ago
  I thought the typo in the challenge was that the keys were in the root of the user's home directory, instead of the `.ssh` directory. So, I added `.ssh/` between the key and user home directory.
• javier2 7y ago
  I love this! How small is a static binary to run this in my containers? How are some ways to integrate the typed config in a language?
  • Gabriel439 7y ago
    The static binaries for the various interpreters and conversion utilities (i.e. `dhall`/`dhall-to-yaml`/`yaml-to-dhall`) are all roughly 10 MB each The following languages natively bind to Dhall: * Haskell * Clojure * Ruby ... and the following language bindings are in progress: * Rust * Go * Python * PureScript In the absence of a native language binding, you can convert Dhall to YAML or JSON and read that in.
• voidmain 7y ago
  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?
  • mbrock 7y ago
    How would you write such a program?
    • comex 7y ago
      let replicate = http://prelude.dhall-lang.org/List/replicate in replicate 999999999999 Natural 1 (add additional nines if necessary)
• ilaksh 7y ago
  I'm sure people will be happy to crucify me for throwing this out there but I don't see a big risk in just using JavaScript in most cases if you want something like that. You could use template literals to replicate the example.
• jrudolph 7y ago
  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: configuration management at scale. We build a multi-cloud management platform, which serves DevOps teams, IT Governance, Controlling and IT Management in large enterprises. That means we're an integration solution for a lot of things, so we need to be highly configurable. Because we also manage private clouds (a la OpenStack, Cloud Foundry, OpenShift etc.), we often run on-premises and operate our software as a managed service. Using dhall allows us to _compile and type check_ all our configuration for all our customers before rolling things out. We use dhall to compile everything from terraform/ansible, kubernetes templates, spring config, to concourse ci pipelines and customer-specific reference data to load into our product. Since adopting dhall earlier this year, we measurably reduced our deployment defect rate and re-gained the ability to safely refactor configuration. It takes a little time to get used to, but we appreciate that it's highly opinionated around formatting and "how to do things" - somewhat in the same way as golang is. It has certainly helped that we had a member with haskell experience on the team, as dhall is built in haskell and the syntax feels familiar. Plug: if you're looking for a job working with dhall, reach out :-) - 0: https://meshcloud.io https://meshcloud.io - 1: https://github.com/Meshcloud/ejs-compiler https://github.com/Meshcloud/ejs-compiler
  • solatic 7y ago
    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.
• hjk05 7y ago
  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 issue, and 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”...
  • eridius 7y ago
    That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.
    • HelloNurse 7y ago
      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).
      • eridius 7y ago
        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.
        • hjk05 7y ago
          Which is odd because tons of applications in the wild already have this amazing capability of directly consuming python and Haskell without first converting to yaml. But of cause you still have the ability to both produce and consume yaml if that’s needed for some reason.