1/ An interesting part of HashiCorp history is that we’ve had over 8 years of experience supporting different configuration paradigms across well-adopted products. Vagrant is pure Ruby, Packer pure JSON, Terraform introduced HCL+JSON which we've adopted into Consul, Nomad, Vault
2/ And we've learned a lot in those 8 years. First, no one paradigm will make everyone happy and quite the opposite, you'll get continuous quite hyperbolic emails/tweets about how your decision was COMPLETELY WRONG, about every paradigm.
3/ A fun event that happens a couple times a year: two strong emails side-by-side with one saying "you should've used a language like JSON" and the other saying "JSON is complete trash, you should've used Ruby." Its clear there is no one winner when you're on the maintainer side.
4/ Then there is the consideration of WHO is approaching this language. I remember certain groups (not devs, not ops either actually) shunning Vagrant a long time because they thought they had to write "code" and they weren't "coders." Regardless of books, examples, etc.
5/ Likewise, people who code are used to having hammers and if a language doesn't give them those hammers it feels equally futile. Even if the same tool is useful to many groups of people.
6/ So let's talk pros/cons in an abridged tweet form. Humans want human readability/understandability and writing enjoyment. Nitpicking commas, quotes, indentation is not fun and not understandable. You can achieve this with DSLs, dynamic languages, and basic langs (ini-style).
7/ Users of software want to perform analysis on configs or auto-generate configs, etc. Machines need or want to read/write configs for software. Type-ambiguity, non-context-free grammars, evaluated languages all are hard for machines. You want a data structure. JSON, YAML, etc.
8/ Humans definitely need comments. This omits a wide swath of data structure or data encoding languages off the bat (JSON). Ignore our past mistakes here, lesson learned and working to resolve those (Packer, hey!). Bonus points: machines reading/writing should preserve comments.
9/ Logic and control flow get tricky. You probably need them, but they start to complicate the machine-readable/writable aspect. Declarative systems help a lot here, but not 100%, and its somewhat of an orthogonal design decision that forms a choice matrix of config/system design
10/ So, the above learnings led eventually to us making HCL. I believe the core tenants and philosophies of this is the right choice: human readable/writable, clear 1:1 JSON mapping, integrated logic language (optional). We SUPER definitely have mistakes along the way, of course.
11/ We're working on fixing those mistakes (hashicorp.com/blog/terraform…). We didn't get things right the first time, but I do believe the core ideas are right and we can get there.
12/ Further, this isn't idealist-driven development, over the years we've surveyed various groups: people who have never used it, beginners, advanced, devs, paying, not paying, etc. and the response from every group has been an overwhelmingly positive experience with HCL.
13/ Anyways, this isn't in response to anything in particularly or a subtweet and its definitely not a rant (I love discussing this stuff). AND I don't mean it as an HCL advert. I just wanted to surface some of my viewpoints and "whys" and history in a string of tweets.
