HCL: Toolkit for Structured Configuration Languages | Hacker News Reader

HCL: Toolkit for Structured Configuration Languages

github.com

27 pointsthunderbong29 comments

Frustration with HCL is why I wrote RCL (it now has a website, https://rcl-lang.org). It can generate HCL's json form for use with Terraform, and it has functions and sensible list comprehensions.

This is tight!

Lovely! HCL is a pain and barely improves. Thank you!

Do you have any plans for an IJ plugin? I saw there are already quite a few grammars in the repo, so kudos for thinking that far ahead

Yes, at some point. It's the IDE I use myself so I definitely want one, but it's also one of the hardest ones to write a plugin for, so I haven't gotten to it yet.

Hey that's cool!

I also wrote BCL (https://github.com/wkhere/bcl) out of frustration with HCL :) (I didn't realize when starting it that the name "BCL" has some bad press for googlers though)

Your project looks very interesting, although we took quite different routes I guess, plus mine is at its quite early stage.

Since finding CUE, it has become by language of choice for anything declarative, it's become my devops superglue.

Great CLI that lets you work with CUE/Yaml/JSON, a Go SDK to get sophisticated, and WASM based bindings to unlock all the other languages.

Have you given Apple's language, Pkl, a try?

https://github.com/apple/pkl

I looked at it, but it has the OOP flaw that CUE is designed to avoid. In other words, overrides are bad and inheritance is a form of override. CUE enables one level of override through defaults or preference marks.

I recommend reading The Logic of CUE to get a gist of the theory

https://cuelang.org/docs/concept/the-logic-of-cue/

i’ll be honest, that article makes it sound like the creators of CUE are really just taking their interest in type theory and applying it wholesale to devops configuration. maybe it’s just late but my eyes were glazing over by the third lattice diagram that really made no sense to me. you seem really into it so i’m sure there’s a reason and i’d like to know what makes it cool, but in more accessible terms like maybe what it lets me do that i couldn’t do in another language. got any links like that?

I have a website I maintain, many people tell me it has helped them

https://cuetorials.com

I've built a monorepo software catalog that solves a number of the complexities in CI, manage most k8s/helm resources with CUE, and built a code gen framework on top of CUE

https://docs.hofstadter.io

To me, I think want sold me was being able to build up large config values from pieces and pattern constraints, know that the system will ensure correctness, and being able to easily inspect that config. Being able to combine CUE with yaml or json in a single CLI call is super handy and helped me when advocating for adoption. You can use CUE to validate existing config or layer a bit on top before having to convince people to change their toolset

That CUE is a logical language makes the learning curve a bit stepper than most other config languages. I've kept it simple for the devs I serve and being a JSON superset makes their modifications to my code an easy ask/lift

I also generate HCL JSON from CUE too, since the OP is about HCL

i’ll check those links out —thanks for taking the time to write up your thoughts!

yeah what they don't mention is that Pkl is based on Java.

you need a 100MB+ runtime to get started with.

But if you are already a Java shop like us, there are even more things to make your complex configs even more complex with pkl gradle plugin.

Of course, you do have to setup and install gradle, and to run gradle you need to install and setup Java JDK.

https://github.com/apple/pkl-go/blob/v0.6.0/.circleci/config... seems to imply it's "curl && chmod" so maybe you're thinking of developing pkl itself?

I happened to have a container that I am certain contains no Java and it fired right up

  $ docker run -it --rm --entrypoint=/usr/bin/env public.ecr.aws/aws-cli/aws-cli:2.15.38 bash -c 'curl -fsSLO https://github.com/apple/pkl/releases/download/0.25.3/pkl-linux-aarch64; chmod a+x pkl-linux-aarch64; ./pkl-linux-aarch64 --help'
  Usage: pkl [OPTIONS] COMMAND [ARGS]...

I've been using Pkl since it came out and I like it a lot, and the editing experience is fantastic with intellij.

I don't think inheritance is a flaw at all here. It makes a lot of sense to build configuration up from base definitions, especially when you account for its merge syntax.

I've been using it for k8s manifests a la customize. The biggest pain point for me is the lack of flat member syntax when updating deeply nested fields.

Something that's caught my eye is KCL, which seems similar, but maybe a bit more mature?

I very much like HCL within terraform, and am glad to have it over yaml or json like in other similar tools. That being said, Hashicorp's other tool, Packer, recently switched to using HCL configs instead of json and I was really disappointed with the results. Under terraform, I found HCL to be quite flexible and found it simple to create customizable modules, where inputted variables affect behavior. The HCL implementation in packer, however, I find to be quite the opposite. I was looking at this about a year ago so I'm sorry I can't be more detailed, and of course things could have changed since then. Anyway, I mention this because I wanted to say despite using HCL for years, encountering the language - a very niche language at that - behaving in completely unexpected ways was not a good thing.

After Hashicorp's recent license change shenanigans I doubt any new OSS project will adopt HCL

especially with OpenTOFU being a thing too

OpenTofu literally _uses_ HCL, with a couple of minor adjustments...

Why? HCL itself is under the MPLv2, and the underpinning go-cty is under MIT. Both of these are perfectly reasonable licenses for even _commercial_ software to use, let alone open source.

Lack of trust in the project's future with the impending sale to IBM.

Why wouldn’t you just use it and fork it if there’s an issue? It’s largely just “finished” at this point. Not everything needs to be churned for years.

HCL has been the infrastructure-as-code language I've enjoyed using most in the last few years of doing platform/DevOps'y stuff. The only time I feel like pulling my hair out is when trying to do complex loops. Anything beyond a simple `for item in items` tends to require a bit of... thinking...

Another take on replacing HCL with something more sensible:

BCL https://github.com/wkhere/bcl

I've been pretty happy with HCL when using Terraform (or Tofu), especially considering there is pretty much no declarative language with a comparably sized ecosystem to match it against.

Most tools and languages that advertise themselves as being a replacement (either for HCL, or Terraform wholesale) are pretty bad in various ways, have no traction (for whatever reason) or lack actual real world usage. One of the biggest things people seem to skip over is the way in which non-software-developers can actually still use it if they come from a sysadmin background. In a way, HCL protects them from falling into the imperative language trap and having to learn software development before being able to do any IaC at all. It's not realistic, and it doesn't work with the people that are already in the field, at scale.

Some tools like SaltStack try to do both, but you end up in the same place where Ansible lives: hiding your declarations in template languages or extensions in imperative languages, at which point you might as well skip the IaC interface and go straight to python or something like that.

HCL is the most ramshackle, poorly thought out "languages" I've encountered. The only thing it has going for it is it attempts to implement a declarative/functional model instead of the lunacy of pulumi encouraging people to have a go with (various) imperative languages.

If you need convincing of the ill-considered nature of HCL, go look at the discussion around adding deep map merge support to terraform and the suggestions to use a third-party provider for this.

My opinion on hcl: better than yaml / json, worse than Python / Typescript / most real languages.

In fact I will use a real programming language for IaC over pretty much anything, as long as the language has an expressive type system and allows declarative idioms.

Based on my build and deployment infrastructure experience, I love declarative approaches, everyone that thinks a general purpose programming language is a good idea for infrastructure code never had to debug deployment issues on big projects.

Great experience if one happens to be the lucky engineer on bench and called in to help out.

Reply on news.ycombinator.com