Why not use UCL, libucl?

[matthewlmcclure]

The Why section at https://github.com/hashicorp/hcl#why doesn't address the question, Why did HashiCorp choose not to use UCL, libucl?

[sethvargo]

Hi @matthewlmcclure

Thank you for opening an issue. This is the first I've learned of UCL, and looking at the git histories, it appears that UCL only existed one year prior to our open source implementation of HCL. It may not have been as prominent at the time, or it may not have met our use case. Nonetheless, we are very happy with HCL, and we enjoy having the freedom and flexibility to control it as we need. Thanks and have a great day!

[matthewlmcclure]

Got it. I had the impression from the HCL README that UCL had inspired HCL,
and that UCL had somehow fallen short of HashiCorp's expectations.

[mitchellh]

@matthewlmcclure You're right!

We did use libucl prior to HCL. There was one really strong motivation to not use libucl: it requires cgo (Go binding to C). We had experience running well-adopted software that uses cgo (Consul used cgo until Consul 0.6) and we learned that while it works quite well, it is preferable to avoid it. I won't go into the reasonings for that here except that was a big reason.

[matthewlmcclure]

Got it! Thanks for the additional historical context!

[mentalisttraceur]

Is there any documentation anywhere about how HCL differs from UCL?

[apparentlymart]

I don't know of any existing, comprehensive documentation on that. Compatibility with UCL is certainly not a goal, so HCL's design has evolved independently in spite of taking inspiration from the general syntax style. Probably best to think of the two as being cosmetically similar, and not take it any further than that.

Here's a non-exhaustive list of some differences I can think of off the top of my head, focusing only on differences from the standpoint of an end-user (not of the Go API):

• UCL is defined as a superset of JSON, whereas HCL treats its native syntax and JSON syntax separately: the two don't mix.
• HCL native syntax uses newlines to separate items, while UCL requires commas or semicolons.
• HCL doesn't have the automatic numeric multiplier suffixes, in spite of some early documentation claiming it did. (This was inherited from when Terraform was directly using UCL)
• HCL doesn't have built-in support for macros or inclusion; this is something that must handled instead at the application layer, if desired.
• At the time of writing, HCL (which will soon be retroactively called "HCL version 1") doesn't have native support for variables or expressions, requiring applications to implement that separately if desired. That will change in the forthcoming version 2, where an expression syntax inspired by the previously-separate HIL will be included in HCL. Once that is released, HCL expressions will be a superset of UCL variables.

As I say, probably better to just think of these as two languages that are superficially similar on the surface but have evolved with some different decisions and goals.