91–100 of 111 posts
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.
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…
I somewhat agree with your point on having an explicit way to indicate JSON input. OTOH, in practice I'd rather prefer having a section about limitations in the docs.
Earlier quoted context omitted.
Don't repeat yourself / single-point-of-truth. Config files can be full of repetition, from values, to sections/objects. Defining a value or object once, dramatically reduces search+replace errors for example.
Is that mutually exclusive with using 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.
> It’s 2024, so RCL has some features that you might expect from a “modern” language: trailing commas I have the opposite opinion here. Commas should be like semi-colons: only required if you want multiple statements on a line. Eg fruit = [ “apples” “oranges” “bananas” ] No commas yet still extremely explicit
Why do you need a comma on a single line in 2024, you already have 2+1 extra symbols/value to separate: quotes and space
otherwise you need parenthesis around expressions with operators: [1 (2 + 3) 4]
unary operators don't create a need for commas, nor the f(x) function call syntax with a single parameter: [1 f(x) ~2 ~f(x)]
now, mild redundancy in syntax is a good thing. it enables detecting whether some code is mistaken (perhaps because a botched copy and paste, for example), giving syntax errors
I know the standard response is "why another one?" but honestly, his diagnosis of the existing options is pretty good. He even uses the best examples of thoughtfully designed config languages: cue, dhall and nix, and ... yeah I pretty much agree with his qualms about those languages. What is a config language really? It's a language that doesn't allow side effects and evaluates to json.
Earlier quoted context omitted.
Why do you need a comma on a single line in 2024, you already have 2+1 extra symbols/value to separate: quotes and space
commas are only really required if there are binary operators: [1, 2 + 3, 4] otherwise you need parenthesis around expressions with operators: [1 (2 + 3) 4] unary operators don't create a need for commas, nor the f(x) function call syntax with a single parameter: [1 f(x) ~2 ~f(x)] now, mild redundancy in syntax is a good thing. it enables detecting whether some code is mistaken (perhaps because a botched copy and pas…
[1 2+3 4]
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
I know the standard response is "why another one?" but honestly, his diagnosis of the existing options is pretty good. He even uses the best examples of thoughtfully designed config languages: cue, dhall and nix, and ... yeah I pretty much agree with his qualms about those languages. What is a config language really? It's a language that doesn't allow side effects and evaluates to json.
Do you really want github actions have no side effects?
Earlier quoted context omitted.
> 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…
Okay, then in your terms my question would be "why is the best language for configuration not an existing language?"
But, like, the answer is because "people had an itch that they couldn't scratch".
Earlier quoted context omitted.
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.
https://blog.boltops.com/2020/10/06/terraform-hcl-nested-loo...
Quote:
Consideration: Updates with Removal
There’s a subtle but important consideration with the current code. It happens when the code gets updated, particularly when previously added elements are removed.
For example, let’s say we first use the code above and run a terraform apply. That creates security groups with rules. Then we delete the rules from the code. Running terraform apply again will not remove the rules.
This is because when there’s an empty List, the for_each loop never iterates. If you wish for the security group rules to maintain its current state set outside of Terraform, you may want this behavior. However, this is probably unexpected and undesirable behavior.
If you want to have Terraform remove all the security group rules, then ingress needs to be assigned directly with a List. We’ll cover how to do that shortly.
Earlier quoted context omitted.
commas are only really required if there are binary operators: [1, 2 + 3, 4] otherwise you need parenthesis around expressions with operators: [1 (2 + 3) 4] unary operators don't create a need for commas, nor the f(x) function call syntax with a single parameter: [1 f(x) ~2 ~f(x)] now, mild redundancy in syntax is a good thing. it enables detecting whether some code is mistaken (perhaps because a botched copy and pas…
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
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 delimiter and having expressions require zero spaces between tokens is adding to a developer’s cognitive overhead. As well as inviting hard to find bugs.