mirror of
https://github.com/tweag/nickel.git
synced 2024-09-11 11:47:03 +03:00
Add kcl comparison (#1730)
* Add kcl comparison * Extend the blurb and add it to the tables * Update README.md Co-authored-by: Yann Hamdaoui <yann.hamdaoui@tweag.io> * Update README.md Co-authored-by: Yann Hamdaoui <yann.hamdaoui@tweag.io> * Update RATIONALE.md Co-authored-by: Yann Hamdaoui <yann.hamdaoui@tweag.io> --------- Co-authored-by: Yann Hamdaoui <yann.hamdaoui@tweag.io>
This commit is contained in:
parent
5c4298f685
commit
b55626bc20
22
RATIONALE.md
22
RATIONALE.md
@ -432,6 +432,27 @@ The main difference between Jsonnet and Nickel are types. Jsonnet does not
|
||||
feature static types, contracts or metadata, and thus can't type library code
|
||||
and has no principled approach to data validation.
|
||||
|
||||
### KCL: python-like syntax with object-oriented schemas
|
||||
|
||||
The KCL configuration language supports validation against object-oriented
|
||||
schemas that can be combined through inheritance and mixins. It has functions
|
||||
and modules, supports configuration merging,
|
||||
and ships with a large collection of validation modules.
|
||||
|
||||
### KCL vs Nickel
|
||||
|
||||
The KCL typesystem feels more nominal and object-oriented than Nickel's:
|
||||
|
||||
- in KCL you specify the name of the schema when you're writing out the object
|
||||
that's supposed to conform to it; in Nickel, you can write out a record first
|
||||
and then apply the contract at some later point
|
||||
- in KCL, schema inheritance and mixins are written explicitly; in Nickel, complex
|
||||
contracts are built compositionally, by merging smaller ones.
|
||||
|
||||
But the bigger difference is that KCL's schema validation is strict while Nickel's
|
||||
is lazy. This may make Nickel better suited to partial evaluation of large
|
||||
configurations.
|
||||
|
||||
### Comparison with other configuration languages
|
||||
<!-- Intentionally duplicated in `README.md`, please update the other one for
|
||||
any change done here -->
|
||||
@ -444,6 +465,7 @@ any change done here -->
|
||||
| Dhall | Static (requires annotations) | Restricted | Lazy | No |
|
||||
| CUE | Static (everything is a type) | No | Lazy | No, but allowed in the separated scripting layer |
|
||||
| Jsonnet | Dynamic | Yes | Lazy | No |
|
||||
| KCL | Gradual (dynamic + static) | Yes | Strict | No |
|
||||
| JSON | None | No | Strict | No |
|
||||
| YAML | None | No | N/A | No |
|
||||
| TOML | None | No | N/A | No |
|
||||
|
@ -276,6 +276,9 @@ The next steps we plan to work on are:
|
||||
language with object-oriented features, among which inheritance is similar
|
||||
to Nickel's merge system. One big difference with Nickel is the absence of
|
||||
typing.
|
||||
- [KCL](https://kcl-lang.io/) is a gradually typed configuration language whose validation
|
||||
is based on object-oriented schemas that can be extended through inheritance.
|
||||
Unlike the languages above, its evaluation is strict.
|
||||
- [Pulumi](https://www.pulumi.com/) is not a language in itself, but a cloud
|
||||
tool (like Terraform) where you can use your preferred language for
|
||||
describing your infrastructure. This is a different approach to the problem,
|
||||
@ -300,6 +303,7 @@ any change done here -->
|
||||
| Dhall | Static (requires annotations) | Restricted | Lazy | No |
|
||||
| CUE | Static (everything is a type) | No | Lazy | No, but allowed in the separated scripting layer |
|
||||
| Jsonnet | Dynamic | Yes | Lazy | No |
|
||||
| KCL | Gradual (dynamic + static) | Yes | Strict | No |
|
||||
| JSON | None | No | Strict | No |
|
||||
| YAML | None | No | N/A | No |
|
||||
| TOML | None | No | N/A | No |
|
||||
|
Loading…
Reference in New Issue
Block a user