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

A reasonable configuration language

ruudvanasseldonk.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: A reasonable configuration language

#71

Post by et1337 »

heads wrote: post #56

Configuration languages are an interface to the API presented by the software you are using. There can be a hard boundary between the two — a C codebase for a web server and the XML-like file that configured it — or there can be an imperceptible transition between the two where the configuration is just another module in the code base. As one of the authors working in a 2000+ module Python codebase, nothing gives me…

Interesting, I’m in the middle of a huge project to move us AWAY from compiling a separate binary for each environment. In our case, I don’t see how hardcoding config values can play nice with infrastructure as code tools, or the need to offer an on-premises version of the app.

Re: A reasonable configuration language

#72

Post by acjohnson55 »

deepsun wrote: post #70

> The kind of thing you’d do with a two-line nested loop ... > that is was far simpler to just copy-paste the config six times. And that's the right way for infrastructure and build configs. You do want over-verbose, no-logic code in the configs. Unlike app code, you rarely need to change it, and readability is even more important. 6 duplicates is not too many yet for infra code. In terms of copy-paste tolerance, I'd…

I agree with you in a lot of situations but I think there are situations where the intention you want to communicate is "these 6 situations are the same, except for this variation, because X". If you duplicate, it can be hard to capture in a way that is as robust. And then you risk logical errors in your configuration, which can be very damaging.

Re: A reasonable configuration language

#73

Post by e12e »

paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

HCL has its quirks - bit I'm not entirely sure they are without merit in this case - HCL describes resources - and it's important that when your iteration count goes down, resources are deleted. Some discussion in sections 6, 7 and 8 (linked):

https://blog.boltops.com/2020/10/08/terraform-hcl-for-in-and...

Re: A reasonable configuration language

#74

Post by paholg »

deepsun wrote: post #70

> The kind of thing you’d do with a two-line nested loop ... > that is was far simpler to just copy-paste the config six times. And that's the right way for infrastructure and build configs. You do want over-verbose, no-logic code in the configs. Unlike app code, you rarely need to change it, and readability is even more important. 6 duplicates is not too many yet for infra code. In terms of copy-paste tolerance, I'd…

And yet, sometimes you do want to reuse code in infra configs and build pipelines. I have definitely wanted to reuse code in hcl, to the point that I wrote a Ruby script to generate it because that was easier than trying to do it in hcl.

Clearly I'm not the only one. Gitlab even sees the use enough to support syntax that is invalid yaml: https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#re...

This, of course, causes yaml-language-server to complain. What I wouldn't give to have a language where I could, say "goto definition" for things like this rather than get LSP errors.

Re: A reasonable configuration language

#75

Post by paulddraper »

aliasxneo wrote: post #54
paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

> but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That's an odd take. Are you saying that because it's newer? I would push something like Crossplane as more "modern" in that it solves the critical issue of Terraform not having any sort of reconciliation loop.

Because it is a (recent) solution to the problem ("how to easily loop, etc in Terraform").

There are Terraform alternatives...Cloudformation, Pulumi, Crossplane...but that's a separate matter.

Re: A reasonable configuration language

#76

Post by paulddraper »

e12e wrote: post #73
paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

HCL has its quirks - bit I'm not entirely sure they are without merit in this case - HCL describes resources - and it's important that when your iteration count goes down, resources are deleted. Some discussion in sections 6, 7 and 8 (linked): https://blog.boltops.com/2020/10/08/terraform-hcl-for-in-and...

> it's important that when your iteration count goes down, resources are deleted

Correct, but that has nothing to do with HCL and everything to do with stored state.

Re: A reasonable configuration language

#77

Post by ljaothasdfs »

Great start! I'd like this even more if you dropped the python-style f-strings for a JavaScript or HCL flavor instead.

You noted at the bottom that RCL type system may take the path of TypeScript. This is brilliant idea because structural type systems match perfectly with a configuration language.

Re: A reasonable configuration language

#78

Post by skybrian »

ianburrell wrote: post #66
skybrian wrote: post #65

Earlier quoted context omitted.

Sure, it doesn't allow side effects, but what can it depend on? If a file defines a language that downloads a dependency from a URL, does that count? How about if it's automatically cached? Once you start getting dependencies from others, it seems like a configuration language could drift into package management.

Downloading anything has side effects and can't be allowed by side effect free language. It is pretty rare that config language allow downloads. Downloading dependencies isn't usually done by config languages. Config languages generate a config, JSON or YAML, from source. The config file can be used by engine that applies the config including downloading dependencies.

XML isn't rare and it has URL's baked in. But yes, it's a bad idea.

Re: A reasonable configuration language

#79

Post by ljaothasdfs »

paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

You are likely already aware of this, but for other readers, you actually have to use Pulumi if you want native language feature support.

I agree CDK for TF can be better than HCL, but it is still more like a template preprocessing utility for Terraform and thus still carries the limitations of Terraform.

Post reply on HN