[HN Gopher] KCL, a constraint-based functional language for conf...
___________________________________________________________________
KCL, a constraint-based functional language for configuration
Author : atombender
Score : 34 points
Date : 2024-08-05 15:42 UTC (7 hours ago)
(HTM) web link (www.kcl-lang.io)
(TXT) w3m dump (www.kcl-lang.io)
| hosh wrote:
| There was that other long thread about using a general purpose
| language to generate Kubernetes manifests. However, just looking
| at this briefly, this may have all the features I care about from
| general-purpose languages.
|
| Although it looks like it is a better replacement for HCL
| (Terraform), I'm thinking this may end up working better than
| Helm.
| hbogert wrote:
| Have you seen timoni? it ticks all my boxes. It uses cuelang
| which admittedly is a steeper learning curve, but o boi, its
| conceptual model is so nice once it 'clicks'
|
| https://timoni.sh/
| aliasxneo wrote:
| We've been using Timoni in production for six months now.
| What a breath of fresh air (and sanity) coming from Helm.
| It's not perfect, but I'll take immature imperfections (that
| are improving by the month) over the YAML/Go templating
| nightmare that is Helm.
| hosh wrote:
| I have not.
|
| However, looking at it now, it falls into the same problems
| all template generators have. Those are things solved by
| using general purpose languages _generate_ rather than
| _templating_ manifests.
|
| KCL is in the middle ground. The Ruby mixins I can use for
| manifest generation can has an equivalence with KCL's union.
|
| I can see Timoni's appeal as it looks like an improvement
| over Helm and integrates building artifacts.
| evanjrowley wrote:
| How does this compare with Nickel?
| kirmerzlikin wrote:
| Here's what KCL authors say about it themselves
|
| https://www.kcl-lang.io/docs/user_docs/getting-started/intro...
| jeffrallen wrote:
| https://xkcd.com/927/
| from-nibly wrote:
| > KCL's automatic merge mechanism for isolated configuration
| blocks promotes high scalability.
|
| This part scares me a bit. How does it merge? In cuelang,
| everything has to agree otherwise it's an error. If KCL has a
| situation where one file can override another, I'm out. That gets
| way too hairy way too fast.
|
| Edit: data0 = {id: 1} | {id: 2} #
| Error:conflicting values between {'id': 2} and {'id': 1}
| data1 = {id: 1} | {id = 2} # Ok, the value of `data` is {"id":
| 2}
|
| There are the foot guns
| drdaeman wrote:
| nixpkgs.lib has mkDefault/mkForce/mkOverride system (which I'm
| not a fond of because of the poor type system, but at least it
| works) that feels like a better approach than this weirdness.
| aliasxneo wrote:
| This seems to be a feature to some people. They must
| exclusively work on tiny, compartmentalized projects.
| Otherwise, I don't understand the allure. We use CUE a lot, and
| when I teach people about this particular constraint (only one
| concrete value is allowed), they get frustrated, as if the
| alternative is better.
| patrick451 wrote:
| What do you mean `{id = 2}` ?
|
| The ROS parameter system does automatic overwriting of values.
| You end up with different subsystems loading different param
| files in the parameter server, with each one overwriting values
| from the last one. It is a complete nightmare.
___________________________________________________________________
(page generated 2024-08-05 23:01 UTC)