3 ms·

Dhall is the most interesting alternative because it can be compiled to JSON easily

capableweb 4y ago
That's like the least interesting feature from Dhall, and also probably one of the most common features of any new format. Not sure I could mention any even semi-popular format that cannot easily be converted to JSON.
- cies 4y ago
  https://dhall-lang.org/ https://dhall-lang.org/ Cool indeed. I wonder how you can supply it with types from the program that consumes the config. My Gradle config is in Kotlin these days. Kotlin, besides being a full blown prog lang, has nice features for config specs (map/list literals, typed, eDSL syntax). Though it is an enormous dependency (way to big for a project that just needs a config file format).
  - piaste 4y ago
    The bigger Dhall type libraries are usually generated from OpenAPI specs - there is a core package that consumes them. If your language has an OpenAPI library, you can create a hello-world web app that exposes your configuration object as an HTTP endpoint, and generate Dhall types from that.
BiteCode_dev 4y ago
After trying both Dhall and Cuelang, I really prefer the latter. But this turns out to support OP's point. JSON is good enough, and there are many alternatives that we are debating and don't agree on. So if you have to pick something, and I have to pick something, since we don't agree, we will fallback on JSON.
- Brian_K_White 4y ago
  man, nailed that
- lioeters 4y ago
  Worse is better, yet again.
- sanderjd 4y ago
  This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy to just pick something better and standardize on that. My current company is pretty much standardized on yaml, which isn't my favorite, but it's fine and better than json and we don't argue about it much. Things get serialized to json pretty often, but most stuff that is checked in and intended to be human readable is not json. A different company could easily pick cue or whatever else and it would work just as well.
  - twic 4y ago
    I think this is a neglected point. For application config, the scope over which standardisation pays off is smaller than for data. It can be company-sized. Or language-sized - if all Ruby library use YAML, that's great for Rubyists; if all Java apps use properties files, that's, believe it nor not, pretty great for Java programmers.
  - kaba0 4y ago
    Huh, yaml is just all around the worst on any metric. I would much rather stick to xml even.
    - sanderjd 4y ago
      Like I said, yaml isn't my favorite either, but this is silly hyperbole; xml is way harder for a human to read and write.

That's like the least interesting feature from Dhall, and also probably one of the most common features of any new format. Not sure I could mention any even semi-popular format that cannot easily be converted to JSON.

cies 4y ago
https://dhall-lang.org/ https://dhall-lang.org/ Cool indeed. I wonder how you can supply it with types from the program that consumes the config. My Gradle config is in Kotlin these days. Kotlin, besides being a full blown prog lang, has nice features for config specs (map/list literals, typed, eDSL syntax). Though it is an enormous dependency (way to big for a project that just needs a config file format).
- piaste 4y ago
  The bigger Dhall type libraries are usually generated from OpenAPI specs - there is a core package that consumes them. If your language has an OpenAPI library, you can create a hello-world web app that exposes your configuration object as an HTTP endpoint, and generate Dhall types from that.

BiteCode_dev 4y ago

After trying both Dhall and Cuelang, I really prefer the latter. But this turns out to support OP's point. JSON is good enough, and there are many alternatives that we are debating and don't agree on. So if you have to pick something, and I have to pick something, since we don't agree, we will fallback on JSON.

Brian_K_White 4y ago
man, nailed that
lioeters 4y ago
Worse is better, yet again.
sanderjd 4y ago
This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy to just pick something better and standardize on that. My current company is pretty much standardized on yaml, which isn't my favorite, but it's fine and better than json and we don't argue about it much. Things get serialized to json pretty often, but most stuff that is checked in and intended to be human readable is not json. A different company could easily pick cue or whatever else and it would work just as well.
- twic 4y ago
  I think this is a neglected point. For application config, the scope over which standardisation pays off is smaller than for data. It can be company-sized. Or language-sized - if all Ruby library use YAML, that's great for Rubyists; if all Java apps use properties files, that's, believe it nor not, pretty great for Java programmers.
- kaba0 4y ago
  Huh, yaml is just all around the worst on any metric. I would much rather stick to xml even.
  - sanderjd 4y ago
    Like I said, yaml isn't my favorite either, but this is silly hyperbole; xml is way harder for a human to read and write.