大家好，国外知名开源大佬 Aliaksandr Valialkin[1]，最近针对即将正式发布的 Go1.23 中的迭代器写了篇文章[2]怒喷。引起了巨大的社区热议。
迭代器这一新特性，有认同也有否定。无论怎么说，Go 新的复杂度来了。今天分享他针对 Go 在 rsc 当权后的现状的看法和对迭代器的不满等看法的文章。
本文原作者 Aliaksandr Valialkin 是 vm、quicktemplate、fastjson、fasthttp、fastcache、easyproto 等的开发者，也算是较为资深的 Go 工程师了。
Go 编程语言因其易用性而广为人知。归功于其精心设计的语法、特性和工具，Go 使得编写任意复杂度的易于阅读和维护的程序成为可能（详见 GitHub）。
图片
然而，一些软件工程师称 Go 为 “无聊”和 “过时”，因为它缺少像：monads、option types、LINQ、borrow checkers、零开销抽象、面向方面编程、继承、函数和运算符重载等特性。
虽然这些特性可能简化特定领域的代码编写，但它们除了带来好处之外，还有额外的成本。
这些特性通常对脑力锻炼有好处。但在处理生产代码时，我们不需要额外的心理负担，因为我们已经忙于解决业务任务。
所有这些特性的主要成本是：
这可能会显著减慢甚至停止代码开发的步伐。这就是 Go 最初没有这些特性的主要原因。
不幸的是，这些特性开始出现在最近的 Go 版本中：
泛型已经在 Go1.18 中添加。许多软件工程师希望在 Go 中添加泛型，因为他们认为这将显著提高他们在 Go 中的生产力。
自 Go1.18 发布以来已经过去了两年，但生产力提高的迹象并不明显。Go 中泛型的总体采用率仍然很低。
为什么？因为在大多数实际的 Go 代码中并不需要泛型。
另一方面，泛型显著增加了 Go 语言本身的复杂性。例如，尝试理解泛型添加后 Go 类型推断的所有细节。它的复杂性已经非常接近 C++ 类型推断了。
Go 泛型还缺少 C++ 模板中存在的基本特性，例如，Go 泛型不支持泛型类型中的泛型方法。它们也不支持模板特化和模板模板参数，以及许多其他特性，这些特性需要充分利用泛型编程。
Range over functions（范围函数），即迭代器、生成器或协程，将在 Go 1.23 中被添加。让我们更仔细地看看这个 “特性”。
如果你不熟悉 Go 中的迭代器，那么请阅读这篇介绍[3]。
本质上，这是一种语法糖，允许在具有特殊签名的函数上编写 for ... range 循环。这听起来像是一个很棒的特性，不是吗？让我们尝试弄清楚这个特性解决了什么实际问题。
在 Go 中，没有一种标准的方式来遍历一系列值。由于缺乏任何约定，最终出现了各种各样的方法。
每种实现都做了在当时的上下文中最有意义的事，但孤立的决策导致了用户的困惑。
以下是一些标准库中存在的不同迭代方式：
• archive/tar.Reader.Next
• bufio.Reader.ReadByte
• bufio.Scanner.Scan
• container/ring.Ring.Do
• database/sql.Rows
• expvar.Do
• flag.Visit
• go/token.FileSet.Iterate
• path/filepath.Walk
• runtime.Frames.Next
• sync.Map.Range
这些函数在迭代的细节上几乎没有一致性。即使在签名上达成一致的函数也不总是同意语义。
例如，大多数返回 (bool, T) 的迭代函数遵循 Go 的常规，即第一个 bool 表示第二个 T 是否有效。
与此相反，runtime.Frames.Next 返回的 bool 表示迭代是否继续。
当你想要遍历某些内容时，你首先必须了解你正在调用的特定代码如何处理迭代。这种不一致性阻碍了 Go 的目标，即在大型代码库中轻松移动。
人们经常提到所有 Go 代码看起来都差不多是一种优势。但对于具有自定义迭代的代码来说，这根本不是真的。
同理，这听起来是合理的 - 在 Go 中有一种统一的方式来遍历各种类型。但是，关于向后兼容性，Go 的主要优势之一呢？
所有上述标准库中的现有自定义迭代器将根据 Go 兼容性规则永远保留在标准库中。
因此，所有新的 Go 版本将至少提供两种不同的方式，在标准库中遍历各种类型 - 旧的方式和新的方式。
这增加了 Go 编程的复杂性，因为：
直到 Go 1.23，for ... range 循环只能应用于内置类型：int（自 Go1.22 起）、string、slice、map 和 channel。
这些循环的语义清晰易懂（channel 的循环语义更复杂，但如果你处理并发编程，那么你应该很容易理解）。
for ... range 循环现在可以应用于函数，这引入了一种新形式的迭代器，称为 pull 和 push 函数。
这使得不可能理解给定的无辜循环体 for ... range 实际上在背后做什么，因为它隐式地将循环体包装在一个匿名函数中，并将其传递给 push 迭代器函数。此外，它隐式地调用匿名 pull 函数，并将返回的结果传递给循环体。
这还隐式地转换了 return、continue、break、goto 和 defer 语句为匿名函数内的非显式语句。
以下是一些示例代码，展示了新迭代器的使用和潜在问题：
// 旧的显式回调方法tree.walk(func(k, v string) { println(k, v) })// 新的 range over function 方法for k, v := range tree.walk { println(k, v) }请记住，后面的循环隐式地转换为带有显式回调调用的前一个代码。现在让我们从循环中返回一些东西：
for k, v := range tree.walk { if k == "foo" { return v }}它隐式地转换为类似于以下内容的难以追踪的代码：
var vOuter stringneedOuterReturn := falsetree.walk(func(k, v string) bool { if k == "foo" { needOuterReturn = true vOuter = strings.Clone(v) // 这里进行了内存分配和复制 return false }})if needOuterReturn { return vOuter}如果 tree.walk 通过从字节切片的不安全转换将 v 传递给回调，那么 v 的内容可能在下一次循环迭代中改变。因此，隐式生成的防弹代码必须使用 strings.Clone()，这可能导致不必要的内存分配和复制。
range over func 特性对函数签名施加了限制。这些限制并不适合所有需要迭代集合项的情况。
这迫使软件工程师在 for ... range 循环的丑陋 hack 和编写理想适合给定任务的显式代码之间做出艰难选择。
遗憾的是，Go 开始朝着增加复杂性和隐式代码执行的方向发展。也许我们需要停止添加增加 Go 复杂性的特性，而应该专注于 Go 的基本特性 - 简单性、生产力和性能。
例如，最近 Rust 开始在性能关键领域取代 Go 的份额。我相信如果 Go 核心团队专注于热点循环的优化，如循环展开和 SIMD 使用，这种趋势可以逆转。
这不应该太影响编译和链接速度，因为只有一小部分编译的 Go 代码需要优化。没有必要优化所有变体的愚蠢代码 - 这些代码即使在优化热点循环之后，仍然会很慢。
只优化软件工程师有意编写的特定模式就足够了，他们关心他们的代码性能。
Go 比 Rust 更容易使用。我们为什么要在性能竞赛中输给 Rust？
另一个 Go 可以在不增加语言本身复杂性和使用这些特性的 Go 代码复杂性的情况下获得的有用特性的例子，是类似于这个的小生活质量改进。
我是 VictoriaMetrics、quicktemplate、fastjson、fasthttp、fastcache、easyproto 等的开发者。感谢 Go，我一直在尝试遵循 KISS 设计原则。
[1] Aliaksandr Valialkin: https://github.com/valyala
[2] 文章: https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1a620
[3] 介绍: https://bitfieldconsulting.com/posts/iterators
本文链接：//www.dmpip.com//www.dmpip.com/showinfo-26-96764-0.html业内大佬怒喷：Go 正朝着错误的方向发展
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： CSS的媒体查询：响应式布局的利器
下一篇： 聊聊性能指标CPU利用率如何计算的？
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
