Hacker News Reader

> Why are so few configuration languages not backed by a real language?

In many cases, not having a full featured language is helpful as you have some additional guarantees that comes with a non Turing complete language like guaranteed completion.

In some cases though, you do need a full pledged programming language. For those cases, HashiCorp recently announced CDK support for Terraform: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

Cool, I hadn't seen CDK for Terraform before. But doesn't this support my point? If they had just used Typescript from the start, they wouldn't have to add Typescript support later.

I suppose guaranteed completion matters if you are running untrusted code, but wouldn't sandboxing solve that? Are there any other guarantees that sandboxing wouldn't solve?

> I suppose guaranteed completion matters if you are running untrusted code, but wouldn't sandboxing solve that? Are there any other guarantees that sandboxing wouldn't solve?

There is more benefits than just that, by restricting the possibilities you know there won't be unbounded loops, analysis and code review is easier (and infrastructure teams are often seriously lagging in this regard), it can be easier to maintain, update and test.

In some cases, you can have a project where this is seriously limiting though because you have some very complex and specific thing you need to express. For this you can use CDK. I would say both approach are complementary, not exclusive.

In my experience I would say nearly all infrastructure projects can be expressed as Terraform rather easily, but YMMV.

You can bring that argument, but only until you decide to use YAML, instead of something declarative and simple like JSON.

Once you switch to something as powerful as YAML, you might as well reach for a real programming language.

Also, YAML is kind of a hack.

Living in Norway I've had quite a few of these situations where no is parsed to False [1].

[1] https://hitchdev.com/strictyaml/why/implicit-typing-removed/

It has been fixed since yaml 1.2

That said, yeah :facepalm:

> powerful as yaml

Can you make an example of the power of yaml that makes it more like a programming language (in particular vs JSON)?

not OP but: tags (custom data types), more builtin data types (dates etc), more syntax variations (heredocuments, multiple ways to write a string,a boolean, etc), comments, references+aliases.

The language is vast, and most people use it without knowing it.

I love YAML, but I wish there was a "strict&sane yaml subset".

All those are good examples of yaml complexity but none of that is anywhere near what even a simple programming language can unleash (variables, loops, functions, recursion etc)

You can do recursion in YAML, and it ends badly: https://en.wikipedia.org/wiki/Billion_laughs_attack#Variatio...

Recursion without termination doesn't produce a useful computation

Can a config mechanism where shell commands are embedded as strings still be considered as offering these additional guarantees?

Perhaps certain things are easier: it's easier to parse, to isolate the code portions, and to read data portions. But then validating what's inside those code portions is a challenge.

It seems like there's an opportunity for a programming language purpose built for the task of configuration. Its chief feature would be the ability to provide a lot of information when read in "inert data" mode, yet also provide full programming language power when read in "run" mode.

ETA: Perhaps embed Python inside something similar to YAML, and support active code via a "lambda" type. Use indentation for delimiting.

   project: "Foo"
   version: "1.0.1"
   email: "me@example.com"
   load:
     lambda file_path:
       pass

Because when you do that, things always go astray as not everyone is that disciplined in what they put on those files.

Tcl, Perl, Python based config files experience in production, means I only touch Gradle when Google forces me to do so on Android.

> I really wish they had both just used "a real programming language" right from the start

There are currently several options, like https://github.com/stripe/skycfg

> Why are so few configuration languages not backed by a real language?

There are tons of tools that work with YAML/JSON but I imagine you mean more like a first-class citizen programming language specific or good at writing static configuration. The other side of the coin is that configuration in many cases have a different audience than programmers (for ex, end users or operations team) and it's a good option to have static configuration key=value than any human can (more or less) read easily without having to run programming code in your head. Plus programming, besides being harder to read and share, introduces bugs. So I suppose the preference between code writing configuration and stand-alone configuration depends on who the consumer is and how complex the configuration is.

This so much.

Every time you have to use another configuration language you have to learn all the quirks (ex: "" == undef in puppet), Give up all your powerful tools (like a debugger) and learn new abstractions. It's extremely counterproductive and it usually would have been better to have simple data structure that you generate from a program written in a traditional language (which the team can artificially restrict to avoid recursion if they want.)

Also IMO there's no such thing as a "declarative language." These are just languages where almost everything has a side affect of mutating a data structure that you don't have an easy way of inspecting or debugging.

using a "real" Turing complete language for configuration is overkill.

But there are two promising projects that could finally make a difference (at least one of them).

https://cuelang.org

https://dhall-lang.org

Everything mentioned in the article can be simply done by writing a kubernetes validation webhook in the language of your choice. Why would you specifically need the configuration to be a real language?

That's one of the things I like about chef. You have an extensible DSL and templating but you can also write Ruby if needed.

k-rail does realtime validation and enforcement with policies written in Go: https://github.com/cruise-automation/k-rail