Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Levels of configuration languages

beza1e1.tuxen.de

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Levels of configuration languages

#41

Post by harshitaneja »

default-kramer wrote: post #38
alexambarch wrote: post #27

I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language. In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to L…

I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be use…

This is exactly how we do it with our very own rudimentary internal library and scripts. Barely enough and even though I worry at times it will break unexpectedly but so far we are surprised by how stable everything has been.

Although I really wish there was a first party solution or a well established library for this but I suspect that while it is easy to build only enough to support specific usecases but building a generic enough solution for everyone would be quite an undertaking.

Re: Levels of configuration languages

#42

Post by danpalmer »

alexambarch wrote: post #27

I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language. In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to L…

The problem with HCL is that it's a Level 4 language masquerading as a Level 3 language, rather than a Level 4 language masquerading as a Level 5 (like Starlark, Dhall, even JSONNET). Because of that its syntax is very limited and it needs awkwardly nuanced semantics, and becomes difficult to use well as a result.

HCL is best used when the problem you're solving is nearly one you could use a level 3 language for, whereas in my experience, Starlark is only really worth it when what you need is nearly Python.

Re: Levels of configuration languages

#43

Post by danpalmer »

bob1029 wrote: post #14

I think SQL is one of the best level 4/5 configuration languages out there. Whether or not it's a "full programming language" depends on your specific dialect and how it's used.

Only if what you specifically want is to represent queries. If what you want to represent is roughly static data then SQL is an incredibly awkward language to use.

Re: Levels of configuration languages

#44

Post by anonymous »

susam wrote: post #7

About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…

No post body was provided.

Re: Levels of configuration languages

#45

Post by retropragma »

As a TypeScript developer, my answer is to use unconfig [1]. Support for JSON, JavaScript, or best of all, TypeScript.

Or wire up your own utility function with bundle-require [2], another favorite of mine, for loading TS or JS config files.

[1]: https://github.com/antfu-collective/unconfig [2]: https://github.com/egoist/bundle-require

Re: Levels of configuration languages

#46

Post by retropragma »

ks2048 wrote: post #33

> I actually like XML. It isn't "cool" like YAML anymore, but it has better tooling support (e.g. schema checking) and doesn't try to be too clever. Just try to stay away from namespaces and don't be afraid of using attributes. I agree with this (even though, In practice I usually just use JSON or YAML) - it avoids some of the pitfalls of both JSON and YAML - has comments, lacks ambiguity. The main annoyances are tex…

Every time I work with XML data, I hate it. Just use JSONC imo.

Re: Levels of configuration languages

#47

Post by jiggawatts »

In my opinion there's a "level 4.5" in between structured templating and full-blown procedural scripting: Using a general-purpose language to generate structured data, but then handing that over to a simpler system to materialise.

Pulumi is the best known example. Also, any time a normal programming language is used to generate something like an ARM template or any other kind of declarative deployment file.

This is the best-of-all-worlds in my opinion: Full capability, but with the safety of having an output that can be reviewed, committed to source control, diff-ed, etc...

Re: Levels of configuration languages

#48

Post by nxnxdndndn »

kristopolous wrote: post #39
hmry wrote: post #26

Earlier quoted context omitted.

Level 4 / total programming languages are not turing complete. Because you can't simulate every turing machine in them, only some subset that provably halts. (And because the halting problem is undecidable, there will always be some turing machines that actually do halt but still can't be simulated because the compiler can't prove it)

It's been edited since I wrote this and it's now 5 instead of 4 It didn't originally use the obscure formal idea of a "total" language

How is a total language obscure? It's a language describing total functions

Re: Levels of configuration languages

#49

Post by bblb »

"vibeconfig"

1. You give LLM the requirements

2. It spits out whatever monstrosity is required to configure the software or service in question

3. When issues later arise, you just vibeconfig again with new requirements

Eventually new vibeconfig tools will rise because even those three steps are not complex enough. These call LLM APIs to inject the config files dynamically at runtime. "But it's a security issue". So another vertical is born: auditing and securing the vibeconfig LLM autogeneration toolsets.

Re: Levels of configuration languages

#50

Post by JanMa »

default-kramer wrote: post #38
alexambarch wrote: post #27

I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language. In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to L…

I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be use…

That actually works quite well. I once built a templating engine for Terraform files based on JQ that reads in higher level Yaml definitions of the resources that should be created and outputs valid Terraform Json config. The main reason back then was that you couldn't dynamically create Terraform provider definitions in Terraform itself.

Later on I migrated the solution to Terramate which made it a lot more maintainable because you write HCL to template Terraform config instead of JQ filters.

Post reply on HN