Hacker News Reader

Comment by kccqzy | Hacker News Reader

Configuration files need to be powerful programming languages (in terms of expressiveness) while being restricted (in terms of network and I/O and non-determinism). We need to aim very high for configuration languages especially when we treat them like user interfaces. Look at Cue (https://cuelang.org/), Starlark or Dhall (https://dhall-lang.org/) for inspiration, not JSON, unless your configuration file is almost always written programmatically.

View on HN

Any configuration language that doesn't support strict/user/explicit types is worthless (ahem jsonnet).

The idea of configuring something but not actually having any sort of assurances that what you're configuring is correct is maddening. Building software with nothing but hopes and dreams.

Or Jsonnet (https://jsonnet.org), if you do like JSON but want less quoting.

expressiveness unfortunately usually means that while you can read the output value, you lose the ability to modify it programmatically...

I don't know that I would particularly _want_ to modify starlark programmatically, but it's certainly not impossible. Build files in bazel for instance are nicely modifiable: https://bazel.build/concepts/build-files.

Only if you stick to the lowest level constructs.

Example with Terraform HCL: if everything was just declared as plain resources, you can modify them trivially. But HCL has functions, so people try to DRY their code by declaring some custom input variable, running maps/filters/reshaping it until it's unrecognizable and them generating a dynamic set of resources out of it. There's no way a program can work through the reverse of all the input reshaping logic to e.g. add another resource without knowledge of the custom input structure.

In RCL you can edit source files programmatically with `rcl patch`: https://ruudvanasseldonk.com/2025/automating-configuration-u...

Reply on news.ycombinator.com