Sat 08 November 2025

我爱 OCaml (I Love OCaml) # https://mccd.space/posts/ocaml-the-worlds-best/

本文作者 Marc Coquand 分享了自己对 OCaml 语言的热爱与深刻理解。他回顾了自己从学习 Haskell 到使用 Go 的经历，指出 Haskell 虽有强大的类型系统和函数式编程优势，但复杂性高、编译慢、运行时易出现难以调试的“空间泄漏”；而 Go 虽然简洁、编译快、工具链完善，却因缺乏空值安全、错误处理繁琐、缺乏 REPL 等，导致代码易出错且开发体验受限。

在对比多种语言后，作者认为 OCaml 完美平衡了简洁与表达力，满足了他对理想编程语言的全部期待：具备强大的静态类型系统、模式匹配、代数数据类型等函数式特性；运行时简单清晰，可预测性能；编译速度极快，优于 Haskell 和 Rust；支持静态编译为单个二进制文件，便于部署；文档完善，拥有 odig 离线查阅工具和 utop 交互式 REPL；类型推断能力强，模块化设计清晰，接口与实现分离，提升可读性。

作者特别赞赏 OCaml 设计者“良好的品味”——在保持语言简洁的同时，保留了必要的表达能力。尽管语言历史悠久，部分特性（如面向对象）略显过时，生态中也有冗余，但整体而言，OCaml 是“真正优秀”的语言。他总结，OCaml 之所以令人着迷，正是因为它在简单与强大之间找到了绝佳平衡，拥有出色的工具链与文档支持，让开发者能专注于创造，而非与语言对抗。

HN 热度 288 points | 评论 196 comments | 作者：art-w | 11 hours ago # https://news.ycombinator.com/item?id=45846517

OCaml 在 Windows 平台上的支持较差，尤其是 OCaml 5 版本后情况更糟。 OCaml 的语法对人类阅读不友好，缺乏标点和段落结构，容易造成“文字迷宫”。 语法错误时，错误信息往往覆盖大量代码行，难以定位问题。 ocamlfmt 格式化工具表现不佳，会将复杂的 match 表达式压缩到一行，影响可读性。 OCaml 的文档过于简略，缺乏实际示例，学习成本高。 OPAM 包管理器理论优秀但实践复杂，存在难以理解的行为和已知 bug，如在 Unix 组超过 32 个时无法找到 curl。 函数签名中可选的类型注解削弱了静态类型带来的文档和错误提示优势。 OCaml 生态规模小，缺少基础功能如文件复制，依赖需自行构建。 函数式语言普遍偏好单链表，但该数据结构在现代场景下效率较低。 F#作为 ML 家族语言，更适合在 Windows 和.NET 平台上使用，拥有更丰富的生态系统和更好的可部署性。 F#的类型推断能力不如 OCaml，需要更多手动类型注解，降低了开发体验。 F#缺少 OCaml 的强命名参数功能，无法实现类似 currying 与命名参数的优雅组合。 F#继承了.NET 的 null 问题，而 OCaml 通过代数数据类型有效避免了空指针异常。 OCaml 的模块系统和结构类型系统远超 F#，具备更强大的类型表达能力。 通过配置 janestreet 风格的 ocamlformat 可改善代码格式化质量。 应该使用.mli 接口文件来弥补缺少类型注解的缺陷，配合 IDE 类型提示可显著提升开发体验。 OPAM 无法找到 curl 的问题实为 musl libc 的限制，非 OPAM 本身 bug。 函数式语言偏好单链表是因为其天然支持不可变性，避免频繁复制。 通过高效实现，如 Clojure 的 vector，可以在保持不可变性的同时实现类似数组的性能。 链表在函数式编程中是表达“首元素 + 剩余部分”逻辑的自然方式，其内存结构并非决定性因素。

Category: @new