41–50 of 67 posts
Nor is it clear to me how the "for loop" version would handle the case where exceptionally one bucket is different. Which is a more interesting discussion imho, that's the whole point of having it as a configuration field, after all.
I'd be curious what the author thinks of KSON, which was also recently featured on HN [1]. [1]: https://news.ycombinator.com/item?id=45291858
The intention behind configuration languages is sound but there’s just too many of them. Not having a universally accepted one makes picking one harder. Also, migrating from one to another isn’t as straightforward. Plus, for database in ["alpha", "bravo"]: for period, days in period_retention_days: At this point, you’re better off writing a Python script that spits out some JSON. I‘m aware that even the blog mentions…
I'll try dig out a link to the talk one of their Flight Software Engineers did on the concept.
I got confused reading this because I wasn't sure how I, as a reader with no knowledge of the system under discussion, was supposed to know that all the buckets should be in the same region. Nor is it clear to me how the "for loop" version would handle the case where exceptionally one bucket is different. Which is a more interesting discussion imho, that's the whole point of having it as a configuration field, after…
region = if name == "bravo-hourly" then "us-west" else "eu-west",Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.
- Turing completeness means that you have to deal with the halting problem, meaning you can't statically ensure that a program ever completes. This is really shit when dealing with config, one buggy while loop or infinite recursive function and stuff just grinds to a halt with no good way of debugging it. Having this problem at the config level might mean that your program never even gets to properly start up, so you never get to setup the logging / otel or whatever you usually use to catch those problems.
- Normal programming languages have side effects and are therefor insecure! They can usually read and write files anywhere, open sockets, send traffic over the internet, etc. These are all properties you don't want of a config language! Especially if you can import code from other modules, a single import statement in a "config file" is now a huge security risk! This is why "npm" keeps having security nightmares again and again and again.
So what you want from a config language is not the same thing as from a programming language, you want as much power as you can get without "Turing completeness" and without any "side effects". That's the reason we have stuff like HCL and whatever the article used as an example.
Earlier quoted context omitted.
I think one of the problems of those "configuration languages" is that you can extract semantic information without knowing the target, e.g., with has a specific meaning in GitHub Actions but it is otherwise an unremarkable word in the YAML specification. But when working with real programming languages it is completely different, you can take semantic information from the current code, and you can have things like t…
The problem is most configuration languages are declarative vs imperative like most “real” languages are. You could probably levy the same complaint against declarative languages in general - it’s just a different way of thinking