业内大佬怒喷：Go 正朝着错误的方向发展

最新推荐文章于 2024-08-14 10:09:58 发布

煎鱼（EDDYCJY）

最新推荐文章于 2024-08-14 10:09:58 发布

阅读量1.1k

点赞数 25

文章标签： golang 开发语言后端

本文链接：https://blog.csdn.net/eddycjy/article/details/139945036

版权

大家好，国外知名开源大佬 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 最初没有这些特性的主要原因。

泛型在 Go1.18 中的引入

不幸的是，这些特性开始出现在最近的 Go 版本中：

泛型已经在 Go1.18 中添加。许多软件工程师希望在 Go 中添加泛型，因为他们认为这将显著提高他们在 Go 中的生产力。

自 Go1.18 发布以来已经过去了两年，但生产力提高的迹象并不明显。Go 中泛型的总体采用率仍然很低。

为什么？因为在大多数实际的 Go 代码中并不需要泛型。

另一方面，泛型显著增加了 Go 语言本身的复杂性。例如，尝试理解泛型添加后 Go 类型推断的所有细节。它的复杂性已经非常接近 C++ 类型推断了。

Go 泛型还缺少 C++ 模板中存在的基本特性，例如，Go 泛型不支持泛型类型中的泛型方法。它们也不支持模板特化和模板模板参数，以及许多其他特性，这些特性需要充分利用泛型编程。

Go 1.23 中的迭代器

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 中迭代器的其他问题

直到 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 string
needOuterReturn := false

tree.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 和编写理想适合给定任务的显式代码之间做出艰难选择。