6 ms·

HCL - why inventing another config/markup language? There TOML, yaml and dozen others.

nunez 9y ago
I think HCL strikes a balance between being too generic (YAML, JSON) and too flexible (Chef, Puppet code) and seems to be better suited for infrastructure automation.
ykler 9y ago
Yes, or a full-featured programming language. Even though I don't really know or like Ruby, I still like that Vagrant uses it for config since it is at least possible to do complex things if you need to.
- zenlikethat 9y ago
  It makes it impossible for the system to reason about the outputs though (due to the halting problem and a lot of other practical issues). Therefore a Vagrant setup just "does its best" to execute the given prescription to set a machine up, whereas something like Terraform will actually intelligently figure out if work needs to be done.
  - eropple 9y ago
    This is a strange assertion--you run the DSL to generate, at runtime, a data model that can then be checked. Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is. (Still not great, because the problem is a hard one, but.) And doing so gives you such niceties as if-statements and loops (I mean, have you seen the straight nonsense people have to pull to make a simple 'if' in HCL?) as well as a seamless way to introduce external data sources. This is why Chef remains the only part of my workflow that has not changed over the last five years (and why first Puppet and, eventually, Ansible will fall by the wayside): because, as a programming language and set of libraries, I can bring it with me by extending it at the user level without having to extend the runtime to do something. Patching the runtime means I need CM for my CM; doing it at the user level means it goes with me and plays with the base tools.
    - chucky_z 9y ago
      In favor of Ansible, I'd argue that extending it is trivial. I tend to write simple Jinja2 filters when I need something done quickly that's not included, and it's as simple as making a specifically named directory (filter_plugins) and a python class (FilterModule). You can write your own modules pretty simply as well but there's a bit more boilerplate.
    - zenlikethat 9y ago
      > Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is. So why is Terraform so popular instead of your tool? :) Both approaches have tradeoffs, and what you've mentioned are clearly advantages of the full-PL config style. The problem with a full-blown programming language, though, is that the flexibility makes it more difficult to reason about effects without actually running the code. If you're just using it to generate a declarative data model that then gets applied, you're still doing fully declarative management, just with extra steps. It's not _necessarily_ a good thing to have something like if conditionals in a provisioning system either - the goal with these systems is usually to reduce uncertainty about outcomes, not multiply the # of branches you need to reason about. Ultimately I agree Terraform has issues with restrictions of HCL, but I don't think I'd say choosing a programming language instead of a purely declarative style is a no-brainer.
  - willtim 9y ago
    I don't understand why you have been downvoted. Many of these tools are very imperative and make assumptions about the starting state before they replay their updates. For a fully declarative solution, NixOS is the best I have seen.
- manojlds 9y ago
  Considering that Vagrant is their most famous tool so far, they should have had a good reason to move to HCL then right? (And they do, as linked in a sibling comment.)
lowmagnet 9y ago
It's mostly JSON. We use this and Terraform and yes, I'd prefer go scripts and a literal library of go code.
schmichael 9y ago
Such a good question there's a section of the README dedicated to it! https://github.com/hashicorp/hcl#why https://github.com/hashicorp/hcl#why
zenlikethat 9y ago
It's really quite a nice config language -- I much prefer HCL to any of the alternatives. Has comments (unlike JSON), is properly nestable (unlike TOML), is extremely human readable and not too verbose, has a built-in pretty printer, etc. I wasn't ever really a huge YAML fan. It's way too ambiguous and sensitive to whitespace. One erroneous space is way more likely to mess up your YAML file than your HCL file. It's not perfect, but I actually would like to see MORE systems using HCL, not fewer.
- willtim 9y ago
  HCL is not used in the rest API though. So we have to integrate our apps using both HCL and JSON. It's also schemaless, which means we have to guess the API using various "samples".
  - zenlikethat 9y ago
    Which REST API?
    - willtim 9y ago
      https://www.consul.io/api/catalog.html https://www.consul.io/api/catalog.html
- daveroberts 9y ago
  How is TOML not properly nestable?
  - zenlikethat 9y ago
    Because in TOML you just specify additional keys after the first one, leading to redundancy and representing a structure that's actually nested as flat. In TOML you can indent but it's not required: [[fruit]] name = "apple" [[fruit.physical]] color = "red" shape = "round" In HCL it's all just one (properly nested) object and you can `fmt` it: fruit { name = "apple" physical { color = "red" shape = "round" } } It seems arbitrary but really matters once you're nesting a few levels deep, which tends to happen in anything complex such as an orchestration system.
vesak 9y ago
FWIW, many OpenBSD tools use a configuration language that's not too far from HCL. I'm much more confused by the industry using the difficult to parse (for both humans and computers) YAML for everything.

I think HCL strikes a balance between being too generic (YAML, JSON) and too flexible (Chef, Puppet code) and seems to be better suited for infrastructure automation.

ykler 9y ago

Yes, or a full-featured programming language. Even though I don't really know or like Ruby, I still like that Vagrant uses it for config since it is at least possible to do complex things if you need to.

zenlikethat 9y ago
It makes it impossible for the system to reason about the outputs though (due to the halting problem and a lot of other practical issues). Therefore a Vagrant setup just "does its best" to execute the given prescription to set a machine up, whereas something like Terraform will actually intelligently figure out if work needs to be done.
- eropple 9y ago
  This is a strange assertion--you run the DSL to generate, at runtime, a data model that can then be checked. Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is. (Still not great, because the problem is a hard one, but.) And doing so gives you such niceties as if-statements and loops (I mean, have you seen the straight nonsense people have to pull to make a simple 'if' in HCL?) as well as a seamless way to introduce external data sources. This is why Chef remains the only part of my workflow that has not changed over the last five years (and why first Puppet and, eventually, Ansible will fall by the wayside): because, as a programming language and set of libraries, I can bring it with me by extending it at the user level without having to extend the runtime to do something. Patching the runtime means I need CM for my CM; doing it at the user level means it goes with me and plays with the base tools.
  - chucky_z 9y ago
    In favor of Ansible, I'd argue that extending it is trivial. I tend to write simple Jinja2 filters when I need something done quickly that's not included, and it's as simple as making a specifically named directory (filter_plugins) and a python class (FilterModule). You can write your own modules pretty simply as well but there's a bit more boilerplate.
  - zenlikethat 9y ago
    > Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is. So why is Terraform so popular instead of your tool? :) Both approaches have tradeoffs, and what you've mentioned are clearly advantages of the full-PL config style. The problem with a full-blown programming language, though, is that the flexibility makes it more difficult to reason about effects without actually running the code. If you're just using it to generate a declarative data model that then gets applied, you're still doing fully declarative management, just with extra steps. It's not _necessarily_ a good thing to have something like if conditionals in a provisioning system either - the goal with these systems is usually to reduce uncertainty about outcomes, not multiply the # of branches you need to reason about. Ultimately I agree Terraform has issues with restrictions of HCL, but I don't think I'd say choosing a programming language instead of a purely declarative style is a no-brainer.
- willtim 9y ago
  I don't understand why you have been downvoted. Many of these tools are very imperative and make assumptions about the starting state before they replay their updates. For a fully declarative solution, NixOS is the best I have seen.
manojlds 9y ago
Considering that Vagrant is their most famous tool so far, they should have had a good reason to move to HCL then right? (And they do, as linked in a sibling comment.)

lowmagnet 9y ago

It's mostly JSON. We use this and Terraform and yes, I'd prefer go scripts and a literal library of go code.

schmichael 9y ago

Such a good question there's a section of the README dedicated to it! https://github.com/hashicorp/hcl#why https://github.com/hashicorp/hcl#why

zenlikethat 9y ago

It's really quite a nice config language -- I much prefer HCL to any of the alternatives. Has comments (unlike JSON), is properly nestable (unlike TOML), is extremely human readable and not too verbose, has a built-in pretty printer, etc. I wasn't ever really a huge YAML fan. It's way too ambiguous and sensitive to whitespace. One erroneous space is way more likely to mess up your YAML file than your HCL file. It's not perfect, but I actually would like to see MORE systems using HCL, not fewer.

willtim 9y ago
HCL is not used in the rest API though. So we have to integrate our apps using both HCL and JSON. It's also schemaless, which means we have to guess the API using various "samples".
- zenlikethat 9y ago
  Which REST API?
  - willtim 9y ago
    https://www.consul.io/api/catalog.html https://www.consul.io/api/catalog.html
daveroberts 9y ago
How is TOML not properly nestable?
- zenlikethat 9y ago
  Because in TOML you just specify additional keys after the first one, leading to redundancy and representing a structure that's actually nested as flat. In TOML you can indent but it's not required: [[fruit]] name = "apple" [[fruit.physical]] color = "red" shape = "round" In HCL it's all just one (properly nested) object and you can `fmt` it: fruit { name = "apple" physical { color = "red" shape = "round" } } It seems arbitrary but really matters once you're nesting a few levels deep, which tends to happen in anything complex such as an orchestration system.

vesak 9y ago

FWIW, many OpenBSD tools use a configuration language that's not too far from HCL. I'm much more confused by the industry using the difficult to parse (for both humans and computers) YAML for everything.