开发一门编程语言的十年历程

渐进式类型：价值 vs. 缺点

• 许多人认同文章中的建议：对于新语言来说，渐进式类型会增加复杂性，却没有相称的收益。更好的做法通常是直接选择静态类型或动态类型（通常是静态类型），并依赖类型推断。
• 也有人认为，当把类型系统改造进大型动态生态时，渐进式类型非常有用（JS→TS、Python、Elixir/Erlang、Raku），或者在需要“逃生舱口”时很有价值（配置 DSL、互操作）。
• 还有人把渐进式系统看作通往静态类型的迁移工具，而不是终点。
• 也有若干评论指出，渐进式系统本身有一个谱系；性能和安全性在很大程度上取决于有类型和无类型代码之间的边界如何被强制执行。

静态 vs 动态：生产力与安全性

• 有人声称，在动态/渐进式类型语言中，他们并不比在静态类型语言中更高效；最初的注解开销会随着时间得到回报。
• 也有人指出，两个方向上的实证证据都有限，并强调生产力取决于问题领域、团队规模、语言生态，以及个人偏好。
• 一个反复出现的批评是：通过弱校验或可选校验（例如默认的 Python/mypy 配置）“发现几个 bug”，如果没有改变测试/工作流，可能会给人一种虚假的安全感。

Python 与渐进式类型在实践中的表现

• 大型带类型注解的 Python 代码库经验喜忧参半：
  • 优点：类型提示改善文档，并能捕捉一些难以复现的 bug。
  • 缺点：第三方 stub 会逐渐与代码脱节，工具默认“失败开放”，而未强制执行或被忽略的注解会产生误导。
• Pyright 因默认比 mypy 更严格而受到称赞。PHP 则被提到会在运行时强制执行渐进式类型，这与 Python 纯静态提示形成对比。

类型检查在概念上很简单，但文档很差

• 几位语言实现者表示，一旦语义固定，类型检查器大体上只是直接的逻辑问题，但好的学习资料非常稀缺。
• 常见的学术书籍被认为太厚重、偏理论，几乎没有具体程序或实用式讲解。
• 贴出了许多博客系列、小型 HM 实现，以及类似“Crafting Interpreters”的资源；显然大家很需要一本平易近人、以实现为中心的类型检查书籍。

其他语言设计与实现主题

• 广泛支持使用现有平台（JVM、BEAM、JS、LLVM、WASM）和工具链，以避免编写自定义代码生成器、链接器或完整工具链。
• 自举被视为成本高昂；有人认为现代 WASM/WASI 的引导让它更可行，但也有人警告不要盲目照搬知名项目。
• S 表达式/Lisp 因解析极其简单、避免语法争论而受到重视；很多人指出，与语法相比，解析很少才是难点，语义和类型系统才是。
• 几位评论者强调：要明确目标用户和问题领域；大多数“边缘”语言仍然只是小众，但即便失败的语言也能贡献想法。