@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 编译速度还是比较慢的，技术选型上完全同意您的看法

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

@littlewing 实际上之后的 Rust 代码主要是对原有 Python 代码的改进，后面的 Rust 代码也会有一部分提升空间，因为是一边学习 Rust 一边重写，相比于 Rust, 题主的 Python 经验更丰富一些，当然原有代码不一定写的好，但是也花了很大精力去优化性能

@centralpark 谢谢，主要是分享一下自己过去工作的经验和教训，现在看主要是技术选型和资源投入上走了弯路。我个人其实用 Python 远大于 Rust

@alexsunxl 当然反过来说 rust 比 C++ 的生态也差了不少，我们在重写过程中发现社区很多 Rust 库都问题不少，但是 C++ 的库就很多了

@wuwukai007 文章中有提到一点点优化的，不过占比不是很大，90% 以上语法解析，语义分析的逻辑就是 1 比 1 重写，具体可以对比 Github 上 kclvm-py 和 KCLVM 两个仓库

@victorc 主要是分享一下过去的工作，现在看应该是技术选型问题和资源问题