Hacker Newsnew | past | comments | ask | show | jobs | submit | peefy's commentslogin

You can search for or look up the corresponding data and evaluation test cases on Hugging Face.


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.


yeah, just because people are doing it doesn't mean it's good. You need to have the strictness of cuelang. But I recognize that KCL will probably win overall cause it's shiny and easy to get started with. But this will cause a LOT of problems for everyone as it already does, with things like json merge patch etc.


A great project!


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


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.


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.


What do you mean by OCI and KCL?


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'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 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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: