peefy

Qt? MAUI?

Sorry, I put wrong link for the article. Here: https://dev.to/xu_pengfei_5bd5de28bc9419/building-personal-a...

Multiple configuration merging strategies do not imply inconsistency or uncertainty, nor do they mean that one file can overwrite or patch another.

KCL also provides a certain degree of immutability, such as ensuring that exported variables are immutable and that configurations in a file cannot be modified. You can only import it and use it to generate new configurations.

In addition, in the cloud native field such as Kubernetes, configuration merging operations can be seen everywhere, such as the built-in JsonMergePatch strategy, Kustomize, and multiple environment configurations for developers. You can find similar corresponding features in KCL.

In fact, KCL also has the idempotent merge operation of cuelang, and languages such as jsonnet, pkl, Nickel also have certain configuration merge capabilities. Only cuelang strictly follows the idempotency of merging, which to some extent limits its use and understanding.

A great project!

It should be added that we also use Rust to fully build the front-end of the language and compile it into native code using LLVM.

I personally enjoy this article very much, just like what we are doing in KCL language [1]. KCL is a cloud native configuration and policy language, and we have endowed KCL with a semantic level gradual type system. It is a bit like Typescript and you use Javascript to write some project configurations with the Typescript type checker, but we have not completely discarded runtime type checking because as a configuration language, we need to strike a balance between efficiency and stability.

But on the other hand, we are currently facing certain challenges. KCL is somewhat ambiguous in grammar and semantics e.g. the record type, and we are working hard to improve it.

[1] https://github.com/kcl-lang

Wonderful post, how about using standard OCI to unify products?

We have also been working hard recently on a package manager for configuring language KCL, which currently supports Git, OCI, and more.

This organization includes 30 language, toolchain and cloud native ecological projects.

As a developer who has been using .NET for many years, C# has given me unprecedented pleasure and efficiency in programming, thanks to a copy of C# code that can be used simultaneously for Linux, Windows, MacOS, Android, iOS, excellent tools, and IDE support.

C# is still one of my favorite programming languages (including syntax, semantics, and standard libraries). Although it is a bit complex now, it has also created many excellent designs such as async, await, and so on.

VS and VS Code are also IDEs that I still use today, although I rarely write C# code.

I have seen its language design and compiler implementation, and I am sure I will continue to follow and watch the development of Yaksha Programming Language. If possible, I would like to contribute.

I'm very surprised that this is actually a single person's workload. "Because I am also a programming language designer and developer, I have worked in it for approximately 3 years, and it also supports compiling to WASM." https://github.com/KusionStack/KCLVM

I'm glad to see the organic combination of Python and Rust. My personal interesting experience is to rewrite a Python project using Rust [1], which has increased the speed by 40 times. Then the original Python project and the rewritten Rust code are organically combined through PyO3, which is very good. We have not only achieved performance, but also achieved ease of use and scalability. Just like PyLint and Ruff.

[1] We Rewrote Our Project With Rust… and It’s Almost 40X Faster. https://medium.com/better-programming/40x-faster-we-rewrote-...

Rust does learn from python, such as crate and module, to some extent. The compilation tool of Rustc itself is written by python, interesting.

With the help of Pyo3, the interoperability between Rust and Python becomes easier. We use Rust to write the performance-sensitive parts and bring the capabilities to Python through binding. The performance-sensitive parts can still be written in Python. After all, Python's ecosystem is slightly richer than that of Rust

Supplement: Although we did not use Go and Python to write the core compiler part of KCL again, we provided KCLVM Go and Python SDK for peripheral ecological supplement: https://kcl-lang.io/docs/reference/xlang-api/overview

I like neat and compact projects!!!

Thank you for your suggestion. At first, we expected to make an SRE-friendly language and made enhancements in configuration and policy writing (try to be close to python and shell in use, and use some pythonic built-in functions such as range). However, this does bring additional learning costs to some users who are unfamiliar with python's usage. We will try to eliminate some of python's triks in the future to make the syntax and semantics of KCL clearer.

Kusion Configuration Language (KCL) is an open source constraint-based record and functional language. KCL improves the writing of a large number of complex configurations such as cloud native scenarios through mature programming language technology and practice, and is committed to building better modularity, scalability and stability around configuration, simpler logic writing, fast automation and good ecological extensionality.

Thank you. Let me check.

Sorry, I didn't understand. Can you provide more information?

Can you give Kyoto Common Lisp more reference information? I'm interested in it.

The KCL website is https://kcl-lang.io/

The core features of KCL are its modeling and constraint capabilities, and the basic functions of KCL revolve around the two core features. In addition, KCL follows the user-centric configuration concept to design its basic functions, which can be understood from two aspects:

Domain model-centric configuration view: With the rich features of KCL language and KCL OpenAPI tools, we can directly integrate a wide range of well-designed models in the community into KCL (such as the K8s resource model). We can also design and implement our own KCL models or libraries according to different scenarios, forming a complete set of domain models for other configuration end users to use.

End user-centric configuration view: With KCL's code encapsulation, abstraction and reuse capabilities, the model architecture can be further abstracted and simplified (for example, the K8s resource model is abstracted into an application-centered server model) to minimize the end user configuration input*, simplify the user's configuration interface, and facilitate manual or automatic API modification.

No matter what configuration view is centered on, for configuration code, there are requirements for configuration data constraints, such as type constraints, required/optional constraints on configuration attributes, range constraints, and immutability constraints. This is also one of the core issues KCL is committed to solving.

Thank you for your liking.

Hello, we are supporting the kpm tool for publishing and sharing KCL modules. To put it simply, we can install and use the modules related to kubernetes through the command: `kpm install kubernetes`. The detailed user stories are here: https://github.com/KusionStack/KCLVM/issues/338

Compared with other languages, you can refer to the relevant documents on the KCL website:

+ https://kcl-lang.io/docs/user_docs/getting-started/intro

+ https://kcl-lang.io/blog/2022-declarative-config-overview

I think the main selling points are the object-oriented model abstraction ability and automation ability. It is close to the writing method of conventional programming language and the automatic processing ability of Data. In Kubernetes and DevOps scenarios, automation is an important means to improve efficiency. https://kcl-lang.io/docs/user_docs/guides/automation

In readme, we only show a simple k8s example. In fact, KCL can achieve a high information compression ratio through its code abstraction capabilities. For example: https://github.com/KusionStack/konfig/blob/main/appops/guest... and https://github.com/KusionStack/konfig/blob/main/appops/guest...

Kusion Configuration Language (KCL) is an open source constraint-based record and functional language. KCL improves the writing of a large number of complex configurations such as cloud native scenarios through mature programming language technology and practice, and is committed to building better modularity, scalability and stability around configuration, simpler logic writing, fast automation and good ecological extensionality.

KCL is an open source constraint-based record and functional language. KCL improves the writing of a large number of complex configurations such as cloud native scenarios through mature programming language technology and practice, and is committed to building better modularity, scalability and stability around configuration, simpler logic writing, fast automation and good ecological extensionality.