Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding more comparison and more aspects to https://kcl-lang.io/docs/user_docs/getting-started/intro/#how-to-choose #274

Open
dzmitry-lahoda opened this issue Feb 14, 2024 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@dzmitry-lahoda
Copy link

dzmitry-lahoda commented Feb 14, 2024

General Question

@Peefy
Copy link
Contributor

Peefy commented Feb 14, 2024

Good suggestions. 👍

It is necessary to supplement these contents in the introduction.

@Peefy Peefy self-assigned this Feb 18, 2024
@Peefy Peefy added the documentation Improvements or additions to documentation label Feb 18, 2024
@Peefy
Copy link
Contributor

Peefy commented Feb 18, 2024

A simple answer:

  1. In KCL, the option function and any type are provided to accept values obtained from outside the KCL program thanks to KCL's runtime type checking, validation, and conversion capabilities. Thus we can interact with the language to complete the processing of unknown values in conjunction with external engines (e.g., KusionStack https://github.com/KusionStack/kusion) or KCL plugins, just like Terraform and HCL. file.tf extends the power of file.hcl.
  1. KCL itself provides many integrations with other languages, formats, and cloud native tools. For example, we can use the kcl vet tool to validate terraform plan files and use the import tool to generate KCL schema from the terraform provider schema, Kubernetes CRD, etc. For cloud native tools, KCL provides almost all the integration of tools you know, thanks to the KRM KCL specification.
  1. Turing decidable, lazy, strict, recursion, side effects of KCL mentioned in the document are right https://github.com/tweag/nickel/blob/master/RATIONALE.md#comparison-with-other-configuration-languages . However, I would like to add that KCL is not strictly evaluated, and its inertia evaluation is based on the schema. For large-scale configurations, KCL also provides incremental compilation and caching to speed up evaluation, and partial runtime maintenance evaluation is not sufficient.
  2. KCL offer multiple merge strategies and operators to override deep dependencies. Of course, there are also idempotence merge for attributes. Besides, we can even use these low level features to implement patch libraries like kustomize/kubectl: https://github.com/kcl-lang/modules/tree/main/strategic_merge_patch which I haven't seen in other languages yet.
  3. I like the vast library of Nix, but I don't use it much. It would be great if you could add relevant comparisons. 😄

Afterwards, I will summarize and organize the PR, and welcome your discussion and review

@dzmitry-lahoda
Copy link
Author

@Peefy thank you. read thought links to get more clarity.

as for Nix. There is NOT Flake Nix with --impure and with --import-from-derivation is very different from pure(hermetic) Flake Nix without import-from-derivation (second one is """"compile time typed"""" kind of). I will concentrate on flake pure nix with import-from-derivation on vs off in comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants