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