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

31–40 of 111 posts

Re: A reasonable configuration language

#31

Post by lolinder »

deathanatos wrote: post #29

I quite like what has been come up with here. In particular, I understand exactly how HCL would drive someone down this path, as it is infuriating to try to get that language to compute what you want computed. I think at the end of the day, k8s YAML is focused on the datatype, i.e., what would be the result of your `rcl evaluate`. I do think this would be a much saner path than what Helm provides, though, and Helm's…

Have you ever run into a case where this distinction matters in practice? If it's a superset of all JSON that actually exists in the wild, that feels functionally the same as being a superset of JSON, even if the spec technically allows edge cases it can't handle.

Re: A reasonable configuration language

#32

Post by Someone »

aleksiy123 wrote: post #13
civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

I think because there are some desirable traits for config languages that don't exist in general purpose languages. Not exhaustive list but generally: Usually constrained to reduce complexity and try to eliminate the need for testing config. Interopable between many different programming languages. Readable by programmers working in different languages. I think this usually makes config languages favour declarative o…

It also is desirable that you can programmatically process configuration files (example: go through all your docker files to determine which ones use vulnerable images)

That is at odds with using a generic Turing complete language, as figuring out what the configuration is requires running code that may do all kinds of weird things (download data, delete files, etc) (that is similar to the postscript/PDF case. To figure out how many pages a postscript file has, you have to run code)

Now, some will say they trust those writing config files to not do stupid things and only use that power when it is absolutely required, but that’s not an opinion shared by all.

Re: A reasonable configuration language

#33

Post by danenania »

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…

You can compile your general purpose language DSL to json and then I think this isn’t too much of a problem.

A bigger issue imo is packaging. General purpose languages aren’t typed well-designed for producing single, understandable standalone files like config languages are. Like I think a simple config DSL in TypeScript could potentially be a perfect way to solve this problem, except that no one wants to lug around a package.json, package-lock.json, and node_modules directory just to write a bit of config. Yet the ability to bring in npm modules—especially those containing relevant types—is where a lot of the attraction of using TypeScript comes from.

Re: A reasonable configuration language

#34

Post by coderedart »

gary_0 wrote: post #15
AtlasBarfed wrote: post #2

The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…

I wonder if anyone would take me seriously if I suggested WASM as a configuration language. When run, the WASM would be given imports that provide a small API for manipulating the config DOM, and importing and executing further WASM files. Then you can use whatever high-level config language you want (or, say, a subset of Rust) and compile it to WASM. Existing JSON/YAML/etc could be compiled to WASM that simply build…

using wasm goes into crazy territory imo. It would probably be bigger, and opaque, with no proper errors (unless you compile debug info which would make it much bigger).

I think we already have an almost perfect language i.e. Lua Everyone knows it (or can learn it easily). tiny runtime to embed. sandboxed by default. garbage collected. Only feature missing is static typing.

Re: A reasonable configuration language

#35

Post by eclectic29 »

Wow! Another configuration language post. 2nd day in a row. And that too on the front page. It's 2024 and the software industry has not solved the problem of configuration yet. Umpteen solutions every year - languages, formats, etc - all for just doing configuration. Just wow! It amazes me. It would be so much better if all the great minds focused on real issues than keep spinning on the hamster wheel of config file formats and languages.

Re: A reasonable configuration language

#36

Post by ncallaway »

civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

> Why do we need special configuration languages? Why not just use existing languages?

Sure, or you could turn around and ask:

Why do we need languages at all? Surely we can express everything with assembly?

Or, shouldn’t one language work for all cases? Why not just use C everywhere?

And the answer becomes obvious: some languages are better at certain tasks than others! Then, a “configuration language” is just going to be a programming language that is best suited to generating configuration.

The same way that C or Rust have different use cases than C# and Java.

Re: A reasonable configuration language

#37

Post by zer00eyz »

Kinrany wrote: post #24
zer00eyz wrote: post #21

The problem isnt "configuration" Yaml, JSON, xml, text files... all work great for configuration. But the assumption is that your configuring a piece of software on an already existing system. A config file as means of setting up a system, installing software, and establishing how its going to run is exceedingly stupid. Write your app so it can run on bare metal, install with apt, yum or your tool(s) of choice for yo…

Are you suggesting that all configuration should be dynamic and multi-tenant (for the lack of a better word), not happen at startup?

Scripting a config file. Templates for config. We did this already, xml, XSD, XSLT, DOM...

It sucked.

Config should be easy and flat and simple. IF it isnt that source it from code, or from a service... Most of the nonsense of config madness is a byproduct of, or hidden in, containers. If we were writing installable software much of that would go away...

Re: A reasonable configuration language

#38

Post by jahewson »

eclectic29 wrote: post #35

Wow! Another configuration language post. 2nd day in a row. And that too on the front page. It's 2024 and the software industry has not solved the problem of configuration yet. Umpteen solutions every year - languages, formats, etc - all for just doing configuration. Just wow! It amazes me. It would be so much better if all the great minds focused on real issues than keep spinning on the hamster wheel of config file…

I spent my PhD working on one of the most pressing problems facing big cloud companies at the time: downtime. The big problem being faced was… configuration.

Re: A reasonable configuration language

#39

Post by OJFord »

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.

Re: A reasonable configuration language

#40

Post by vaylian »

eclectic29 wrote: post #35

Wow! Another configuration language post. 2nd day in a row. And that too on the front page. It's 2024 and the software industry has not solved the problem of configuration yet. Umpteen solutions every year - languages, formats, etc - all for just doing configuration. Just wow! It amazes me. It would be so much better if all the great minds focused on real issues than keep spinning on the hamster wheel of config file…

What in your humble opinion is a real issue that should be addressed instead?
Post reply on HN