Golang 提案：container/：通用集合类型

关于通用容器提案的总体反应

• 许多人欢迎标准化的通用集合（集合、类型化堆等），认为“来得晚总比不来好”。
• 一些人认为这能直接让“普通代码”更容易编写，因为不用再手写容器和样板代码。
• 另一些人担心这会加速 Go 偏离其最初极简主义身份。

Go 中的泛型：契合度与理念

• 有几位认为，泛型最终对于惯用的库来说是必要的（集合、JSON/API 包装器、通道辅助函数）。
• 批评者说，泛型与早期设计选择并不完全契合（例如，不允许在外部类型上定义方法），导致了别扭的模式和运行时替代方案。
• 支持者说，这一设计优先考虑泛型使用者的可读性，而不是泛型作者的易用性，并且保持了较快的编译时间。

简单性 vs. 能力

• 一派重视 Go 的“YAGNI”式简单性，认为更多特性会打开“花哨”且更难维护代码的大门。
• 另一派反驳说，Go 从来就不在“帕累托前沿”上；它的简单性往往把复杂性推给用户代码（重复实现容器、类型断言）。
• 有人感叹 Go 正在收敛成像 Java 那样“企业化/庞大”的语言，失去其作为简单替代品的定位。

Map/迭代器与函数式风格

• 围绕 Map/filter 风格操作的争论：
  • 正方：对常见转换模式来说，代码更短、更清晰；当数据被视为不可变时更容易推理。
  • 反方：Go 的 lambda 更啰嗦，内联能力更弱，因此不够易用；显式 for 循环更清楚也更灵活。
• 有人认为迭代器/流很强大且可组合；也有人指出它们带来了新的失败模式（例如停止迭代时的误用）。

错误处理与易用性

• 有人希望 Go 采用更简洁、可组合的错误处理结构；现有模式被认为噪音较多，并且过于强调“坏路径”。
• 也有人坚持显式错误检查是核心优势，而对语法糖的尝试在 Go 的模型里会有设计陷阱。

历史、时机与“浪费的努力”

• 多条评论认为，几年里抵制泛型造成了大量替代代码和技术债。
• 也有人回应说，语言演进总会带来一些“浪费”，而团队推迟泛型是为了避免 Java/C++ 式的复杂性。
• 向后兼容保证意味着标准库必须缓慢而谨慎地演进；有些人接受这一点，也有人觉得令人沮丧。

比较、生态与未来

• 讨论中频繁拿 Rust、Java、C#、Smalltalk、Lisp、JavaScript、.NET 和 JVM GC 作比较；大家对于 Go 是在追赶还是在失去差异化看法不一。
• 一些人认为 Go 的成功主要归功于 Google、Docker 和 Kubernetes；另一些人则认为它的运行时、部署模型和工具链本身就站得住脚。
• 对 Go 长期方向并没有明确共识：有人愿意“继续观望”，也有人考虑转向功能更丰富的语言。