runtime - Tony Bai

标签 runtime 下的文章

Rob Pike的“抱怨”与Go的“解药”：直面软件膨胀的四大根源

四月 27, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/04/27/rob-pike-on-bloat

大家好，我是Tony Bai。

今年年初，Go语言之父、UTF-8编码的发明者Rob Pike的一篇题为”On Bloat”（关于膨胀）的演讲幻灯片(在2024年下旬做的)在技术圈，尤其是在Hacker News(以下简称HN)上，引发了相当热烈的讨论。Pike作为业界泰斗，其对当前软件开发中普遍存在的“膨胀”现象的犀利批评，以及对依赖管理、软件分层等问题的深刻担忧，无疑戳中了许多开发者的痛点。

HN上的讨论更是五花八门，开发者们纷纷从自身经历出发，探讨“膨胀”的定义、成因和后果。有人认为膨胀是“层层叠加的间接性”导致简单修改寸步难行；有人认为是“不必要的功能堆砌”；还有人归咎于“失控的依赖树”和“缺乏纪律的开发文化”。

那么，Rob Pike究竟在“抱怨”什么？他指出的软件膨胀根源有哪些？而作为我们Gopher，Go语言的设计哲学和工具链，能否为我们从纯技术层面提供对抗膨胀的“解药”呢？今天，我们就结合Pike的演讲精髓和HN的热议，深入聊聊软件膨胀的四大根源，并从Go的视角尝试寻找一下应对之道。

“膨胀”的真相：远不止代码大小和运行速度

在深入探讨根源之前，我们需要认识到，“膨胀”并不止是字面意义上我们理解的最终编译产物的大小或者应用的运行速度慢，Pike的观点和HN讨论中的“软件膨胀”体现在多个维度：

复杂性失控： 过度的抽象层次、复杂的依赖关系、难以理解的代码路径，使得维护和迭代变得异常困难。
维护成本剧增： 添加新功能的长期维护成本（包括理解、测试、修复Bug、处理兼容性）远超初次实现的成本，但往往被低估。
不可预测性与脆弱性： 庞大且快速变化的依赖树使得我们几乎无法完全理解和掌控软件的实际构成和行为，任何更新都可能引入未知风险。

下面我们具体看看Pike指出的“膨胀”几个核心根源：

根源一：特性 (Features) —— “有用”不等于“值得”

Pike 指出，我们不断地为产品添加特性，以使其“更好”。但所有特性都会增加复杂性和成本，而维护成本是最大的那部分，远超初次实现。他警示我们要注意“有用谬论” —— 并非所有“有用”的功能都值得我们付出长期的维护代价。

HN讨论也印证了这一点：功能冗余、为了匹配竞品或满足某个高层“拍脑袋”的想法而添加功能、甚至开发者为了个人晋升而开发复杂功能的现象屡见不鲜。

技术层面：Go的“解药”在哪？

简洁哲学： Go从设计之初就强调“少即是多”，鼓励用简单的原语组合解决问题，天然地抵制不必要的复杂性。
强大的标准库： Go 提供了功能丰富且高质量的标准库，覆盖了网络、并发、加解密、I/O 等众多领域，减少了对外部特性库的依赖。很多时候，“自己动手，丰衣足食”（使用标准库）比引入一个庞大的外部框架更符合Go的风格。
关注工程效率： Go的设计目标之一是提高软件开发（尤其是大型项目）的工程效率和可维护性，这促使Go社区更关注代码的清晰度和长期成本。

注：技术层面包括语言、工具以及设计思路和方法。

根源二：分层 (Layering) —— 在错误的层级“打补丁”

Pike 认为，现代软件层层叠加（硬件 -> 内核 -> 运行时 -> 框架 -> 应用代码），当出现问题时，我们太容易在更高的层级通过包装（wrap）来“修复”问题，而不是深入底层真正解决它。这导致了层层叠叠的“创可贴”，增加了复杂性和维护难度。他列举了ChromeOS文件App的例子，并强调要在正确的层级实现功能和修复。

在HN的讨论中，有开发者描述的修改按钮颜色需要穿透17个文件和多个抽象层的例子，正是这种“错误分层”或“过度抽象”的生动体现。

技术层面：Go的“解药”在哪？

小接口哲学： Go 鼓励定义小而专注的接口，这使得组件之间的依赖更清晰、更松耦合。当问题出现时，更容易定位到具体的接口实现层去修复，而不是在外部层层包装。
组合优于继承： Go 通过组合（struct embedding）而非继承来实现代码复用，避免了深度继承带来的复杂性和脆弱性，使得在“正确层级”修改代码更易操作。
显式错误处理： if err != nil 的模式强制开发者在调用点处理错误，使得问题更难被“隐藏”到上层去统一“包装”处理，鼓励在错误发生的源头附近解决或添加上下文。

根源三：依赖 (Dependencies) —— 看不见的“冰山”

这是Pike演讲中着墨最多、也最为忧虑的一点。他用数据（NPM 包平均依赖 115 个其他包，每天 1/4 的依赖解析发生变化）和实例（Kubernetes 的复杂依赖图）强调：

现代软件依赖数量惊人且变化极快。
我们几乎不可能完全理解自己项目的所有直接和间接依赖。
依赖中隐藏着巨大的维护成本、Bug 和安全风险。
简单的 npm update 或 audit 无法解决根本问题。

他强烈建议要理解依赖的成本，严格、定期地审视依赖树，并推荐了 deps.dev 这样的工具。

HN 社区对此深有同感，纷纷吐槽“为了一个函数引入整个库”、“脆弱的传递性依赖”、“供应链安全”等问题，并呼唤更好的依赖分析工具。

技术层面：Go的“解药”在哪？

Go Modules： 相比 NPM 等包管理器，Go Modules 提供了相对更好的依赖管理机制，包括语义化版本控制、go.sum 校验和、最小版本选择 (MVS) 等，提高了依赖的可预测性和安全性，但也要注意Go module并非完美。
强大的标准库： 这是 Go 对抗依赖泛滥的最有力武器。很多功能可以直接使用标准库，避免引入外部依赖。
社区文化： Go 社区相对而言更推崇稳定性和较少的依赖。引入一个大型框架或过多的外部库在 Go 社区通常需要更充分的理由。
工具支持： Go 提供了 go mod graph, go mod why 等命令，可以帮助开发者理解依赖关系。结合 deps.dev，可以在一定程度上实践 Pike 的建议。

根源四：开源模式 (Open Source Development) —— “大门敞开” vs “严格把关”

Pike 对比了两种开源开发模式：

“真正的开源方式” (The true open source way): 接受一切贡献 (Accept everything that comes)。他认为这是膨胀和 Bug 的巨大来源。
更好的方式： 设立严格的代码质量、标准、评审、测试、贡献者审查等“门槛”，对允许合入的内容有标准。这种方式维护成本低得多。

他暗示 Go 项目本身更倾向于后者，强调“先做好再提交”（make it good before checking it in）。可能很多Gopher也感受到了这一点，Go项目本身对代码质量的review非常严格，这一定程度上也“延缓”了一些新特性进入Go的时间点。

HN 的讨论中也涉及了类似 “Bazaar vs Cathedral” 的模式对比，但观点更加复杂，认为现实中的项目往往处于两者之间的某个位置，并且“完全不接受外部贡献”也并非良策。

技术层面：Go的“解药”在哪？

Go 自身的开发模式： Go 语言本身（由 Google 主导）的开发流程相对严谨，对代码质量和向后兼容性有较高要求，可以看作是“严格把关”模式的体现。
标准库的设计： Go 标准库的设计精良、接口稳定，为开发者提供了一个高质量的基础平台，减少了对外部“随意贡献”的依赖。
社区项目实践： 观察 Go 社区一些知名的开源项目，其贡献流程和代码标准通常也比较严格。

反思与现实：Go 也非万能，“警惕与纪律”仍是关键

虽然 Go 的设计哲学和工具链在对抗软件膨胀方面提供了许多“天然优势”和“解药”，但我们必须清醒地认识到，Go 语言本身并不能完全免疫膨胀。

正如 Pike 在其“建议”(Advice) 中反复强调的，以及 HN 讨论中部分开发者指出的，最终软件的质量很大程度上取决于开发者和团队的“警惕与纪律” (vigilance and discipline)：

我们是否真正理解并避免了增加不相称成本的特性？
我们是否努力在正确的层级解决问题？
我们是否审慎地评估和管理了每一个依赖？
我们是否坚持了高标准的开发和评审流程？

如果缺乏这些，即使使用 Go，项目同样可能变得臃肿、复杂和难以维护。同时，HN 讨论也提醒我们，软件膨胀背后还有更深层次的组织、文化和经济因素，这些往往超出了单纯的技术和开发者纪律所能解决的范畴。

小结：拥抱 Go 的简洁，但需务实前行

Rob Pike 的“抱怨”为我们敲响了警钟，Hacker News 的热议则展现了软件膨胀问题的复杂性和普遍性。它确实是我们在工程实践中需要持续对抗的“熵增”现象。

Go 语言以其简洁、显式、组合的设计哲学，以及强大的标准库和相对稳健的依赖管理，在技术层面上，为我们提供了对抗膨胀的有力武器。理解并拥抱这些 Go 的“基因”，无疑能在一定程度上帮助我们构建更健康、更可持续的软件系统。

当然，Pike 的观点也并非金科玉律。有批评者指出，他的视角可能带有一定的“NIH（非我发明）倾向”，并且存在两个关键的“盲点”：

忽视了“不使用依赖”同样是巨大的技术债。 每一行自写的代码都需要永远维护。
现实中的选择往往不是“使用依赖 vs 自己实现”，而是“使用依赖 vs 根本不做这个功能”。 面对复杂的合规要求（如 ADA、GDPR）、第三方集成或 FIPS 认证等，从零开始构建的成本（可能需要数百人年）往往让“自己实现”变得不切实际。为了让产品能够及时上线并满足用户（哪怕是 Pike 本人可能也在使用的“缓慢”网站）的需求，引入依赖和一定的“膨胀”有时是必要且务实的选择。

注：“NIH（非我发明）倾向”是一种心理现象，指的是人们对他人提出的想法或创新持有偏见，通常因为这些想法不是自己发明的。这种倾向使得人们倾向于低估或拒绝其他人的创意，尽管这些创意可能是有价值的。

这种批评也提醒了我们，虽然 Pike 对简洁和纪律的呼吁值得我们高度重视，但在真实的商业环境和复杂的工程约束下，我们必须做出务实的权衡。纯粹的技术理想有时需要向现实妥协。

最终，我们每一位 Gopher 都需要在理解 Go 简洁之道的同时，保持批判性思维和务实态度。 在日常的每一个决策中，审慎地权衡简单与复杂、理想与现实、引入依赖与自主掌控，才能在这场与“膨胀”的持久战中，找到最适合我们项目和团队的平衡点，交付真正有价值且可持续的软件。

你如何看待 Rob Pike 对软件膨胀的观点？你认为他的批评切中要害，还是忽视了现实的复杂性？欢迎在评论区分享你的思考与实践！

参考资料

Rob Pike – On Bloat – https://docs.google.com/presentation/d/e/2PACX-1vSmIbSwh1_DXKEMU5YKgYpt5_b4yfOfpfEOKS5_cvtLdiHsX6zt-gNeisamRuCtDtCb2SbTafTI8V47/pub?slide=id.p
HN：On Bloat – https://news.ycombinator.com/item?id=43045713
Pike is wrong on bloat
On Bloat – https://commandcenter.blogspot.com/2025/02/on-bloat-these-are-slides-from-talk-i.html

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

自定义Hash终迎标准化？Go提案maphash.Hasher接口设计解读

四月 17, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/04/17/standardize-the-hash-function

大家好，我是Tony Bai。

随着Go泛型的落地和社区对高性能自定义容器需求的增长，如何为用户自定义类型提供一套标准、安全且高效的Hash计算与相等性判断机制，成为了Go核心团队面临的重要议题。近日，经过Go核心开发者多轮深入探讨，编号为#70471 的提案”hash: standardize the hash function”最终收敛并被接受，为Go生态引入了全新的maphash.Hasher[T] 接口，旨在统一自定义类型的Hash实现方式。

这个旨在统一自定义类型Hash实现的提案令人期待，但我们首先需要理解，究竟是什么背景和痛点，促使Go社区必须着手解决自定义 Hash 的标准化问题呢？

1. 背景：为何需要标准化的Hash接口？

在Go 1.18泛型发布之前，为自定义类型（尤其是非comparable类型）实现Hash往往需要开发者自行设计方案，缺乏统一标准。随着泛型的普及，开发者可以创建自定义的哈希表、集合等泛型数据结构，此时，一个标准的、能与这些泛型容器解耦的Hash和相等性判断机制变得至关重要。

更关键的是安全性。一个简单的func(T) uint64类型的Hash函数看似直观和易实现，但极易受到Hash 洪水攻击 (Hash Flooding DoS) 的威胁。

什么是Hash洪水攻击呢？ 简单来说，哈希表通过Hash函数将键（Key）分散到不同的“桶”（Bucket）中，理想情况下可以实现快速的O(1)平均查找、插入和删除。但如果Hash函数的设计存在缺陷或过于简单（例如，不使用随机种子），攻击者就可以精心构造大量具有相同Hash值的不同键。当这些键被插入到同一个哈希表中时，它们会集中在少数几个甚至一个“桶”里，导致这个桶形成一个长链表。此时，对这个桶的操作（如查找或插入）性能会从O(1)急剧退化到O(n)，消耗大量CPU时间。攻击者通过发送大量这样的冲突键，就能耗尽服务器资源，导致服务缓慢甚至完全不可用。

Go内建的map类型通过为每个map实例使用内部随机化的 Seed（种子）来初始化其Hash函数，使得攻击者无法预测哪些键会产生冲突，从而有效防御了此类攻击。hash/maphash包也提供了基于maphash.Seed的安全Hash计算方式。因此，任何标准化的自定义Hash接口都必须将基于Seed的随机化纳入核心设计，以避免开发者在不知情的情况下引入安全漏洞。

明确了标准化Hash接口的必要性，尤其是出于安全性的考量之后，Go核心团队又是如何一步步探索、权衡，最终从多种可能性中确定接口的设计方向的呢？其间的思考过程同样值得我们关注。

2. 设计演进：从简单函数到maphash.Hasher

围绕如何设计这个标准接口，Go 团队进行了广泛的讨论（相关issue: #69420, #69559, #70471）。

最初，开发者们提出的 func(T) uint64 由于无法有效防御 Hash 洪水攻击而被迅速否定。

随后，大家一致认为需要引入Seed，讨论的焦点则转向Seed的传递和使用方式：是作为函数参数（func(Seed, T) uint64）还是封装在接口或结构体中。对此，Ian Lance Taylor提出了Hasher[T]接口的雏形，包含Hash(T) uint64和Equal(T, T) bool方法，并通过工厂函数（如 MakeSeededHasher）来管理 Seed。然而，这引发了关于Seed作用域（per-process vs per-table）和状态管理（stateless vs stateful）的进一步讨论。

Austin Clements 提出了多种接口变体，并深入分析了不同设计的利弊，包括API 简洁性、性能（间接调用 vs 直接调用）、类型推断的限制以及易用性（是否容易误用导致不安全）。

最终，为了更好地支持递归Hash（例如，一个结构体的Hash需要依赖其成员的Hash），讨论聚焦于将*maphash.Hash对象直接传递给Hash方法。maphash.Hash内部封装了Seed和Hash状态，能够方便地在递归调用中传递，简化了实现过程。

经历了对不同方案的深入探讨和关键决策（例如引入 *maphash.Hash），最终被接受并写入提案的maphash.Hasher[T] 接口究竟长什么样？它的核心设计理念又是什么呢？接下来，让我们来详细解读。

3. 最终方案：maphash.Hasher[T]接口

经过审慎评估和实际代码验证（见CL 657296和CL 657297），Go团队最终接受了以下maphash.Hasher[T]接口定义：

package maphash

// A Hasher is a type that implements hashing and equality for type T.
//
// A Hasher must be stateless. Hence, typically, a Hasher will be an empty struct.
type Hasher[T any] interface {
    // Hash updates hash to reflect the contents of value.
    //
    // If two values are [Equal], they must also Hash the same.
    // Specifically, if Equal(a, b) is true, then Hash(h, a) and Hash(h, b)
    // must write identical streams to h.
    Hash(hash *Hash, value T) // 注意：这里的 hash 是 *maphash.Hash 类型
    Equal(a, b T) bool
}

该接口的核心设计理念可以归纳为如下几点：

Stateless Hasher: Hasher[T] 的实现本身应该是无状态的（通常是空结构体），所有状态（包括 Seed）都由传入的 *maphash.Hash 对象管理。
安全保障: 通过强制使用maphash.Hash，确保了 Hash 计算过程与 Go 内建的、经过安全加固的Hash算法（如 runtime.memhash）保持一致，并天然集成了Seed 机制。
递归友好: 在计算复杂类型的 Hash 时，可以直接将 *maphash.Hash 对象传递给成员类型的 Hasher，使得递归实现简洁高效。
关注点分离: 将 Hash 计算 (Hash) 和相等性判断 (Equal) 分离，并与类型 T 本身解耦，提供了更大的灵活性（类似于 sort.Interface 的设计哲学）。

下面是一个maphash.Hasher的使用示例：

package main

import (
    "hash/maphash"
    "slices"
)

// 自定义类型
type Strings []string

// 为 Strings 类型实现 Hasher
type StringsHasher struct{} // 无状态

func (StringsHasher) Hash(mh *maphash.Hash, val Strings) {
    // 使用 maphash.Hash 的方法写入数据
    maphash.WriteComparable(mh, len(val)) // 先写入长度
    for _, s := range val {
        mh.WriteString(s)
    }
}

func (StringsHasher) Equal(a, b Strings) bool {
    return slices.Equal(a, b)
}

// 另一个包含自定义类型的结构体
type Thing struct {
    ss Strings
    i  int
}

// 为 Thing 类型实现 Hasher (递归调用 StringsHasher)
type ThingHasher struct{} // 无状态

func (ThingHasher) Hash(mh *maphash.Hash, val Thing) {
    // 调用成员类型的 Hasher
    StringsHasher{}.Hash(mh, val.ss)
    // 为基础类型写入 Hash
    maphash.WriteComparable(mh, val.i)
}

func (ThingHasher) Equal(a, b Thing) bool {
    // 优先比较简单字段
    if a.i != b.i {
        return false
    }
    // 调用成员类型的 Equal
    return StringsHasher{}.Equal(a.ss, b.ss)
}

// 假设有一个自定义的泛型 Set
type Set[T any, H Hasher[T]] struct {
    hash H // Hasher 实例 (通常是零值)
    seed maphash.Seed
    // ... 其他字段，如存储数据的 bucket ...
}

// Set 的 Get 方法示例
func (s *Set[T, H]) Has(val T) bool {
    var mh maphash.Hash
    mh.SetSeed(s.seed) // 使用 Set 实例的 Seed 初始化 maphash.Hash

    // 使用 Hasher 计算 Hash
    s.hash.Hash(&mh, val)
    hashValue := mh.Sum64()

    // ... 在 bucket 中根据 hashValue 查找 ...
    // ... 找到潜在匹配项 potentialMatch 后，使用 Hasher 的 Equal 判断 ...
    // if s.hash.Equal(val, potentialMatch) {
    //     return true
    // }
    // ...

    // 简化示例，仅展示调用
    _ = hashValue // 避免编译错误

    return false // 假设未找到
}

func main() {
    // 创建 Set 实例时，需要提供具体的类型和对应的 Hasher 类型
    var s Set[Thing, ThingHasher]
    s.seed = maphash.MakeSeed() // 初始化 Seed

    // ... 使用 s ...
    found := s.Has(Thing{ss: Strings{"a", "b"}, i: 1})
    println(found)
}

这个精心设计的 maphash.Hasher[T] 接口及其使用范例展示了其潜力和优雅之处。然而，任何技术方案在落地过程中都难免遇到挑战，这个新接口也不例外。它目前还面临哪些已知的问题，未来又有哪些值得期待的发展方向呢？

4. 挑战与展望

尽管 maphash.Hasher 接口设计优雅且解决了核心问题，但也存在一些已知挑战：

编译器优化: 当前 Go 编译器（截至讨论时）在处理接口方法调用时，可能会导致传入的 *maphash.Hash 对象逃逸到堆上，影响性能。这是 Go 泛型和编译器优化（#48849）需要持续改进的地方，但核心团队认为不应因此牺牲接口设计的合理性。
易用性: maphash.Hash 目前主要提供 Write, WriteString, WriteByte 以及泛型的 WriteComparable。对于其他基础类型（如各种宽度的整数、浮点数），可能需要更多便捷的 WriteXxx 方法来提升开发体验。
生态整合: 未来 Go 标准库或扩展库中的泛型容器（如可能出现的 container/set 或 container/map 的变体）有望基于此接口构建，从而允许用户无缝接入自定义类型的 Hash 支持。

综合来看，尽管存在一些挑战需要克服，但maphash.Hasher[T]接口的提出无疑是Go泛型生态发展中的一个重要里程碑。现在，让我们对它的意义和影响做一个简要的总结。

5. 小结

maphash.Hasher[T]接口的接受是Go在泛型时代标准化核心机制的重要一步。它不仅为开发者提供了一种统一、安全的方式来为自定义类型实现 Hash 和相等性判断，也为 Go 生态中高性能泛型容器的发展奠定了坚实的基础。虽然还存在一些编译器优化和 API 便利性方面的挑战，但其核心设计的合理性和前瞻性预示着 Go 在类型系统和泛型支持上的持续进步。我们期待看到这个接口在未来Go版本中的落地，以及它为Go开发者带来的便利。

更多信息:

GitHub Issue: https://github.com/golang/go/issues/70471
相关 CL (maphash): https://go.dev/cl/657296
相关 CL (go/types): https://go.dev/cl/657297 (展示了该接口在 go/types 包中的应用)

对于这个备受关注的 maphash.Hasher 接口提案，你怎么看？它是否满足了你对自定义类型 Hash 标准化的期待？或者你认为还有哪些挑战或改进空间？

非常期待在评论区看到你的真知灼见！

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：