bcl VS noyaml

Another take on replacing HCL with something more sensible:

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

I agree with you that HCL sucks when it comes to variables.

Other thing that is funny: no user-defined functions, being unable to use function calls in string interpolations, but allowing variables... so it is like saying: we have this parser and at some points it allows expressions, at some other point not. This seems wrong.

At the same time I agree or at least understand original author's intent to squeeze HCL to maxinum. There is something appealing in HCL visual form, at least when defining resources. Maybe it's just (almost) simplest form of defining such structures that can exists.

This is why I started to work on my own format for configuration, visually similar but with different model of evaluation.

Here is the first attempt: https://github.com/wkhere/bcl

Disclaimer: I named it BCL, 'B' stands for Basic, to somehow relate to HCL and make it easily pronounced. But later I discovered that another BCL is used as Google to configure the Borg platform and seems to be massively hated ;) So I look for the better name..

I am crafting BCL, own configuration language.

https://github.com/wkhere/bcl

I started this when I was unable to squeeze certain usage patterns from HCL, like: variables living in the same scope as the file, evaluating variables in one pass with parsing, easily using external (environment) variables; plus, a simplified syntax.

The implementation is mostly done: you can defined blocks holding key-value pairs and use numerical, string and bool expressions in them. I will add lists and nested blocks.

At this very moment I am rewriting a parser from yacc-based to a Pratt top-down parser with vm, heavily inspired by the excellent book "Crafting Interpreters".

https://github.com/wkhere/bcl

Will not immediately help for all of YAML usages, but at least for defining resources in a Terraform-like style. In fact, it's already it's already helpful as a replacement for HCL in one internal project, that was a final motivation to hack it.

In a bigger picture, I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems in a $daily_job is how crude is consolidating a final Helm chart from different sources. I am not saying that Helm would be inherently a bad tool or my company has chosen pretty bad way of using it - I guess everyone is doing their best considering the ciscumstances. But manipulating textual templates is just too error prone, and the detection of errors happens too late. I dare to say - Kubernetes would do much better with custom format based on a C-like syntax, instead if trying to prove how cool YAML is, especially when it isn't.

Related:

just few days ago I crafted together some ideas i had couple of years already for a configuration language, syntactically like HCL but without HashiCorps idiosyncrasies.

Here it goes, BCL (_Basic_ Configuration Language, for a lack of better name yet), Go prototype, I can code Python port and possibly several other as well..

https://github.com/wkhere/bcl

Most commonly written in YAML, these files are large and complex to read and understand. And being written in YAML comes with its challenges (and quirks) since it is an additional programming language that devs need to learn.

YAML is kind of like C++:

> You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :)

https://eli.thegreenplace.net/2009/10/17/the-c-bashing-seaso...

The YAML footguns are too numerous to reproduce here, so here are some sources:

https://stackoverflow.com/questions/3790454/how-do-i-break-a...

https://www.arp242.net/yaml-config.html

https://noyaml.com/

Relevant: https://noyaml.com/

YAML and its ecosystem is full of footguns and ergonomics problems, especially when the length of the document extends beyond the height of a user's editor or viewport. Loss of context with indentation, non-compliant or unsafe parsers, and strange boolean handling to name a few.

It becomes even worse when people decide that static YAML data files should have variable substitution or control flow via templating. "Stringly-typed programming" if you will. If we all started writing JSON text templates I think a lot of people would rightly argue we should write small stdlib-only programs in Python, Typescript, or Ruby to emit this JSON instead of using templated text files. Then it becomes apparent that the YAML template isn't a static data file at all, but part of a program which emits YAML as output. We're already exposing people to basic programming if we're using YAML templates. People brew a special kind of YAML-templated devops hell using tools like Kustomize and Helm, each of which are "just YAML" but are full of idiosyncracies and tool-specific behaviour which make the use of YAML almost coincidental rather than a necessity.

Yes, sometimes people would prefer to look at YAML instead of JSON, in which case I suggest you use a YAML serialization library, or pipe output into a tool like `yq` so you can view the pretty output. In a pinch you could even output JSON and then feed it through a YAML formatter.

The Kubernetes community seems to have this penetrating "oh, it's just YAML" philosophy which means we get mediocre DSLs in "just YAML" which actually encode a lot of nuanced and unintuitive behaviour which varies from tool to tool.

Look at kyverno, for examle: it uses _parentheses_ in YAML key names to change the semantics of security policies! https://kyverno.io/docs/writing-policies/validate/ . This is different to what I think is the (much better ideas of) something like kubewarden, gatekeeper, or jspolicy, which allow engineers to write their policies in anything that compiles to WASM, OPA, and Typescript/Javascript respectively.

We engineers, as a discipline, have decades of know-how building and using general purpose programming languages with type checkers, linters, packaging systems, and other tools, but we throw them all away as soon as YAML comes along. It's time to put the stringified YAML templates away and engage in the ecosystem of mature tools we already to use to perform one simple task they are already good at: dumping JSON on stdout.

Let's move the control flow back into the tool and out of the YAML.

The webpage documenting some of the sharp edges of yaml is also displayed as an editable yaml document

https://noyaml.com/

It’s the least secure config format, even worse than XML IMO since it’s unsafe even with trusted inputs. https://noyaml.com/