tweag/nickel
1
1
Fork 0
mirror of https://github.com/tweag/nickel.git synced 2024-09-11 11:47:03 +03:00
Code Issues Projects Releases Wiki Activity

Add kcl comparison (#1730)

Browse Source 
* 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:
jneem 2023-12-04 04:59:01 -06:00 committed by GitHub
parent 5c4298f685
commit b55626bc20
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 26 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
RATIONALE.md
View File

@ -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 |

4
README.md
View File

@ -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 |