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

101–110 of 111 posts

Re: A reasonable configuration language

#101

Post by rco8786 »

DrBazza wrote: post #93
rco8786 wrote: post #19

Earlier quoted context omitted.

Is that mutually exclusive with using your normal programming language as a config language?

Can you use your normal programming language as a config language? Config is dynamically parsed at runtime. Do you want to bundle a c++ compiler in your code, for example? Config shouldn't be difficult to write, or to parse and process. Perhaps zig and rust can be used as configuration languages as they both do some interesting things that other languages don't.

I don’t see why you can bundle a YAML parser but not a Javascript parser

> Config shouldn't be difficult to write

Couldn’t agree more! In fact, it doesn’t matter if it’s hard to parse. Because that’s what computers are good for. What a human does is write and read configs. Whatever we can do to make that easier we should do.

Using a known programming language, rather than a dedicated confit language, means the user is already familiar with the language and uses it day to day. That’s easy. What’s hard is learning a totally separate language with its own rules, syntax, tool chain, and capabilities.

Re: A reasonable configuration language

#102

Post by catlifeonmars »

patrickmay wrote: post #57
catlifeonmars wrote: post #51

Earlier quoted context omitted.

There’s no smooth gradient between data format and Turing complete programming language. Let’s say I want environment conditional logic (such as looking up a map of AMIs to AWS regions), but don’t want to allow arbitrary code execution, or I want to embed the parser inside the service that accepts the config. Those are the niches that HCLs fill. A programming language that allows you to enable language constructs ind…

> There’s no smooth gradient between data format and Turing complete programming language. S-expressions beg to differ.

Funny you should mention that, I implemented an S-expression based language spelled using JSON for a dynamic configuration use case. It was actually not terrible for a day or two of work, but it was a far cry from a general purpose production grade configuration language due to lack of tooling, intellisense, and a small stdlib. Also, many people found the syntax foreign and confusing; not a deal breaker but just another hurdle.

FWIW I agree with you, but driving adoption would be hard.

Re: A reasonable configuration language

#103

Post by rco8786 »

Jtsummers wrote: post #25
rco8786 wrote: post #19

Earlier quoted context omitted.

Is that mutually exclusive with using your normal programming language as a config language?

What do you do when your normal programming language stops being your normal programming language (you add a language, switch languages), but you want to preserve details of the configuration? Translate it all into your new language(s)? How do you keep these things synced up? You extract the details into a configuration language/serialization format and then deserialize in every language you work with. Embedding your…

Is that a real problem to be solved? Do you switch languages in an existing project that often? When you do, do you just copy/paste your config files or do we have to rebuild them in whatever config language the new language uses?

Re: A reasonable configuration language

#104

Post by eviks »

hnlmorg wrote: post #100
eviks wrote: post #96

Earlier quoted context omitted.

it's needed if you use space within, otherwise [1 2+3 4] doesn't need a comma, and the rule "if you value space in values, quote/bracket those" is a fine simple rule Redundancy is also a bad thing, it's a tradeoff, so the proper approach is to allow enabling it for those and in those case when the value of the good part is higher

That example syntax has so many potential footguns though. I’m not someone that subscribes to the notion that saving keystrokes increases productivity (eg function key words being “fn”). I only think it’s worthwhile removing tokens if they add to the cognitive overhead. In the case of trailing semicolons and commas, it’s something you need to remember to add. So why not make it optional? However using whitespace as a…

In the case of non-trailing commas it's exactly the same - something you need to remember to add. And remember to (re)move when you move arguments around, that's also buggy cognitive overhead.

Expressions don't require zero spaces, use (), this was just an illustration that there is no need for a comma.

Re: A reasonable configuration language

#105

Post by hnlmorg »

eviks wrote: post #104
hnlmorg wrote: post #100

Earlier quoted context omitted.

That example syntax has so many potential footguns though. I’m not someone that subscribes to the notion that saving keystrokes increases productivity (eg function key words being “fn”). I only think it’s worthwhile removing tokens if they add to the cognitive overhead. In the case of trailing semicolons and commas, it’s something you need to remember to add. So why not make it optional? However using whitespace as a…

In the case of non-trailing commas it's exactly the same - something you need to remember to add. And remember to (re)move when you move arguments around, that's also buggy cognitive overhead. Expressions don't require zero spaces, use (), this was just an illustration that there is no need for a comma.

> In the case of non-trailing commas it's exactly the same - something you need to remember to add. And remember to (re)move when you move arguments around, that's also buggy cognitive overhead.

That’s exactly why I’m advocating that trailing commas should be optional ;)

> Expressions don't require zero spaces, use (), this was just an illustration that there is no need for a comma.

You’re example specifically stated using zero spaces for expressions though. So that’s what I’m replying to.

I have no issues with parentheses being used to denote an expression. In fact that largely mirrors how my own language works.

Re: A reasonable configuration language

#106

Post by rirze »

OJFord wrote: post #39
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#.

I use Terraform because of HCL, the absolute best thing about it is the declarative config; if someone insists on using their favourite general purpose language: 1) they're wrong; 2) there's plenty of other options for that and I'm not interested in fighting in Terraform's corner knowing they won't use it for the most fundamental reason it's good.

You do know all that CDKTF does is compile programming language code to JSON (1:1 with Terraform's HCL)?

CDKTF is not accessing the Terraform state directly, it's allowing you to express your configuration that you would normally write in Terraform in a programatic way.

Re: A reasonable configuration language

#107

Post by AndyKluger »

I want to showcase one way to do the example jq/non-jq query using yamlpath:

  yaml-get -p '.tags[has_child(amd)][parent()].name' machines.json
That can replace

  rcl query --output=raw machines.json '[
    for m in input:
    if m.get("tags", []).contains("amd"):
    m.name
  ]'

Re: A reasonable configuration language

#108

Post by PinkSheep »

Although I'm late to the party, I'm surprised by only 4 mentions of "Lua" in all of comments.

At its basis, a valid Lua file can consist of one table. Then the data description will be very similar to how people operate with JSON files. At any point the user is able to write code or use other standard library functions... which is pretty limited, but at the same time it's easy to sandbox plain Lua away from "dangerous" functions such as os.exec or the debug library.

There are only a few caveats:

- Lua uses a 64-bit IEEE float format with some truncated precision

- The standard interpreter doesn't handle very huge tables for parsing

- Treating .lua as code, not data, you'd likely prepend "return " to your table to just receive the table object from the config file

- Unkeyed arrays start from 1, though storing at index 0 is possible

- Cascading of data definitions is possible, like fall-through from one semi-filled table to the default table. Use the __index metamethod

Personally I find Lua's table syntax vastly more readable than JSON. Although the language naturally has comments, the parser ignores them, if that's something you want. But the same workaround works: just store the comment in some keyname_comment value.

Apart from sandboxing you'd only need to limit the script execution time to stop attempts like "while true; end"

PS: Lua started as a configuration language. Wiki:

> Lua's predecessors were the data-description/configuration languages SOL (Simple Object Language) and DEL (data-entry language).

Re: A reasonable configuration language

#109

Post by senorsmile »

raphinou wrote: post #4

jsonnet[1] and kapitan[2] are the tools I currently use. Their learning curve is not optimal (and I tried to contribute to smoothen it with a jsonnet course[3] and a 'get started wit kapitan' blog post[4]), but once used to it it's hard to do without, and their combination makes them even more useful (esp. if you deploy K8s). In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configure…

Kapitan sounds interesting. It definitely looks difficult to figure out. Even your blog post only gives me a hint, leaving me with lots of questions. I am going to o dig deeper.

Re: A reasonable configuration language

#110

Post by alledm »

senorsmile wrote: post #109
raphinou wrote: post #4

jsonnet[1] and kapitan[2] are the tools I currently use. Their learning curve is not optimal (and I tried to contribute to smoothen it with a jsonnet course[3] and a 'get started wit kapitan' blog post[4]), but once used to it it's hard to do without, and their combination makes them even more useful (esp. if you deploy K8s). In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configure…

Kapitan sounds interesting. It definitely looks difficult to figure out. Even your blog post only gives me a hint, leaving me with lots of questions. I am going to o dig deeper.

Kapitan founder here! Please reach out on the kapitan channel of the kubernetes slack, or connect with me on LinkedIn https://www.linkedin.com/in/alledm

I have been working on a couple of video tutorials that could be helpful to get started

Post reply on HN