peefy

@accelerise 感谢反馈，复杂度、学习成本包含生态等确实是值得考虑的点。对 kcl 来说无非几个选择，1.让自己持续简单 2. 可以用通用语言来编写 3. 可以通过 yml/json 来声明

@tool2d 感谢反馈，我们也再尝试扩展的方式充当胶水层而非直接平替的方式作能力维度的增强。

@HiCode 嗯嗯，蚂蚁开源的项目

@Hanggi OPA 是一个策略引擎，Rego 是其策略语言，KCL 更侧重配置的基础上附加类型和结构约束定义，更合适配置场景，当然也可以使用 kcl-vet 工具将 KCL 当作策略语言来使用，两个语言的核心场景、设计理念还是有些差异

看样子即使提案还需要在 CPython 中做大量的开发测试工作.. 目前 GIL 导致多线程搞不了性能提升，用多进程折腾吧..

@xuyang2 确实是的，基于 Helm chart 的模版编程和以及当遇到复杂需求当 values.yaml 需要 fork 修改 helm chart template 等痛点，我们在尝试使用 KCL 做一些工作改善 Helm 体验的工作，比如开箱即用的 k8s 模型和校验规则，使用 KCL Schema 自定义校验和使用 KCL 为 Helm 编写 transformer 等工作。会在后续的文章逐渐透出。

@xyzxiaoking 目前是有一系列内置模版 schema 和抽象 ，具体可以参考后续的文章或者这里的文档内容 https://kcl-lang.io/docs/user_docs/guides/working-with-konfig/overview 。另外我们正在逐步完善 kube2kcl 工具，支持现有 yaml 转到 kcl 和为已有的 yaml/kustomize/helm 编写 transformer, validator 等，后续会逐步完善并开源。

@matrix1010 嗯嗯，是的。这块代码没有处理好，加上更早期的时候没有给 py 代码加 type hints ，对 python 的不熟悉导致后续加 type hints 的时候向 mypy 这种工具很难没错误的利用起来，工程性做的不是很好。

@Hanggi Rust 编译速度还是比较慢的，技术选型上完全同意您的看法