Java Stream 与 Go 的泛型缺口

Java 11 出来时，我想到的不是版本号本身，而是之前代码里留过的一个 TODO 终于可以收掉了：等新版本支持 Stream 的 takeWhile 优化。

这个 feature 虽然在 Java 9 就有，但 9 和 10 都是短命版本，很多团队不会专门为了这类增强去折腾升级。到了 11 这种长期支持版本，才更像是可以认真用起来的时间点。

我一直觉得，Java 8 引入 Stream 是一件影响被低估了的事。

因为它并不只是多了几个函数式 API，而是把大量原本只能靠 for 循环、if 嵌套手写的集合处理逻辑，拉到了一个更统一、更可组合的抽象层上。

这类抽象一旦用顺手，人的心智会发生变化。你会越来越习惯用 pipeline 去思考数据处理过程，而不是每次都回到命令式循环细节里。

也正因为这样，很多人从 Java 切到 Go 时，会明显感觉少了点什么。

问题往往不在“Go 没有库”，而在于在泛型出现之前，Go 很难自然长出一套真正通用、类型安全、又足够好用的集合处理抽象。

没有泛型时，这类库要么写起来很别扭，要么用起来很别扭，最后很难成为大家默认接受的主流风格。

所以这件事其实挺能说明一个更底层的问题：

某些库层抽象之所以成立，不只是因为有人愿意实现它，而是因为语言本身已经把它所需的类型能力和表达方式准备好了。

从这个角度看，Stream 不只是 Java 的一个 API 设计，而是语言和标准库一起配合出来的一种编程体验。

而 Go 在泛型补上之前，很难完整复制这种体验，也不奇怪。

原微博中的媒体