本文永久链接 – https://tonybai.com/2026/03/09/hardcore-review-13-languages-ai-favorite-go-performance

大家好，我是Tony Bai。

随着 Claude Code、Gemini Cli、Codex 等 AI 编程工具的全面普及，“让 AI 写代码”已经从极客的玩具变成了日常的生产力。随之而来的是一个触及灵魂的问题：哪种编程语言最适合交给 AI 去写？

作为 Gopher，我们一直为 Go 语言的“极简语法”、“极速编译”和“强类型安全”感到自豪。我们理所当然地认为，这种没有任何隐式魔法、像白开水一样的语言，绝对是 LLM 的最爱。

然而，现实总是比直觉更骨感。近日，Ruby 核心提交者 Yusuke Endoh（@mame）发布了一份名为 ai-coding-lang-bench 的硬核定量测评报告。他使用 Claude Code（Opus 4.6 模型）对 13 种主流编程语言进行了系统性横向对比。

在这场涵盖了动态语言、静态语言和函数式语言的混战中，Go 语言的表现究竟如何？ 是力压群雄，还是黯然失色？那些备受人类推崇的静态类型系统，在 AI 面前是否成了累赘？

本文和大家一起阅读和拆解这份报告，为你揭晓 AI 时代的语言偏好图谱。

实验设计：让 AI 写一个 Mini-Git

在评价这份报告之前，我们先来看看它的实验设计，这是目前业内少见的、针对 AI Agent 的工程化能力的量化评估。

任务目标：让 Claude Code (Opus 4.6) 从零开始实现一个 mini-git（简化版的 Git）。这是一个极具代表性的任务，它包含了文件 I/O、哈希计算、数据结构操作以及命令行接口，足以考验模型对语言生态的综合运用能力。

测试被巧妙地分为两个阶段，模拟了真实的软件生命周期：

• v1 (新项目构建)：实现基础的 init, add, commit 和 log。
• v2 (特性扩展)：在 v1 的基础上，增加 status, diff, checkout, reset, rm, show 等复杂指令。

提示词（Prompt）极其极简：“阅读 SPEC-v1.txt，实现它，并确保 test-v1.sh 测试通过。”这种设计最大程度地减少了人类指令的干预，纯粹考验 AI 代理在闭环环境下的自主编码、调试和测试能力。

参赛选手（13种语言/15种配置）：

• 动态语言：Python, Ruby, JavaScript, Perl, Lua
• 动态+类型检查器：Python/mypy, Ruby/Steep
• 静态语言：TypeScript, Go, Rust, C, Java
• 函数式语言：Scheme (动态), OCaml (静态), Haskell (静态)

每种语言配置运行 20 次，以消除 LLM 生成的随机性带来的误差，并统计其耗时（Time）、成本（Cost，即 Token 消耗）和代码行数（LOC）。

核心发现：动态语言逆袭，Go 位居第二梯队

如果仅看总耗时和总成本（v1 + v2），测试结果呈现出了令人瞩目的阶梯式分布。

第一梯队：Ruby, Python, JavaScript 的绝对统治

在这场 AI 编程竞速中，Ruby（73.1s）、Python（74.6s）和 JavaScript（81.1s）组成了无可争议的第一阵营。

它们不仅生成速度最快、消耗 API 成本最低（均在 $0.40 以下），而且在 20 次测试中表现出了极高的稳定性（标准差极小）。

对于 AI 来说，生成这三种语言的代码就像呼吸一样自然。它们无需繁琐的项目初始化配置（如 Cargo.toml 或 package.json），可以做到“建个文件直接跑”，这种极简的工作流在 v1 阶段（新项目构建）优势极大。

第二梯队：被“强类型”拖慢脚步的 Go 与 Java

现在，来回答大家最关心的问题：Go 表现如何？

答案是：位居第二梯队。Go 的总耗时为 101.6s，平均成本 $0.50。中规中矩。Go 虽然在语法上非常克制，但依然落后于 Python 和 JS 等动态语言。与之类似，Java（115.4s）也因为繁琐的语法结构和强类型约束，留在了这一梯队。

尽管如此，Go 在整个 20 次测试中没有出现一次失败（0 次 fail），这证明了 Go 的编译器在防止 AI 产生“幻觉 Bug”方面，发挥了极其可靠的安全网作用。

“后进生”阵营：Rust 与 C 的挣扎

备受人类极客推崇的 Rust（113.7s，且有 2 次失败）和底层的 C（155.8s）在测试中显得步履维艰。

尤为值得注意的是，在总共 600 次的独立运行中，只有 Rust (2次) 和 Haskell (1次) 出现了测试失败（未能最终跑通 Shell 脚本）的情况。这两门语言都以其极高的心智负担和“编译器教你做人”的严格程度而闻名。

这也是将Rust列入“后进生”阵营的主要原因。如果用《飞驰人生》的拉力赛来比喻，Rust 相当于在40站的赛季中，有两站没能完赛！

深度剖析：为什么 AI 更偏爱动态语言？

在传统的工程视角中，“静态类型防止低级 Bug”、“动态语言难以维护”是金科玉律。但在 LLM 驱动的 Agent 开发流中，这个逻辑为何失效了？作者 Yusuke Endoh 提出了几个关键的解释维度。

训练数据的“虹吸效应”

LLM 的能力直接取决于训练语料的规模和质量。Python、JavaScript 和 Ruby 是过去十几年 Web 开发的绝对主流。GitHub 上海量的这三种语言的开源代码、StackOverflow 上的问答，为 Claude Code 提供了极其丰富的“预训练肌肉记忆”。

当 AI 需要实现一个功能时，它在 Python 的隐空间（Latent Space）中寻找最优解的路径，远比在 Haskell 甚至 Rust 中要清晰、笔直得多。

静态类型的“双刃剑”与重构阻力

静态类型系统的初衷是约束人类，防止我们在重构时犯错。但在 AI 的“ Prompt -> 生成 -> 测试报错 -> 思考 -> 再生成”的迭代循环中，严格的类型检查反而成了巨大的“摩擦力”。

• 编译成本与调试死锁：在 Rust 或 C 中，当 AI 生成的代码出现类型不匹配时，它需要花费大量的 Token 去阅读复杂的编译器报错信息。有时，为了解决一个简单的借用检查器（Borrow Checker）报错，AI 可能会陷入漫长的、无休止的“试错-编译失败”死循环。
• 重构牵一发而动全身：在 v2 特性扩展阶段，往往需要修改现有的数据结构。对于 Python，AI 只需要在字典里加个 key；而对于 Rust 或 Java，这可能意味着需要重构一系列的 Struct、更新类型签名、甚至修改与之相关的无数个函数的参数声明。这种“爆炸半径”极大地增加了耗时。

“附加类型检查”的巨大损耗

报告中一个非常有意思的对照组是：原生动态语言 vs 附加类型检查器的动态语言。

• Python (74.6s) vs Python/mypy (125.3s) —— 变慢了 1.6~1.7 倍。
• Ruby (73.1s) vs Ruby/Steep (186.6s) —— 变慢了 2.0~3.2 倍！

这证明了，迫使 AI 在动态语言中编写严谨的类型注解（Type Annotations），是一项极其昂贵的任务。模型需要耗费额外的算力去推导类型、生成类型声明文件，并且在类型检查器报错时，还要去修复那些在纯动态模式下可能根本不影响运行的“伪 Bug”。

代码量（LOC）的迷思：越短越好吗？

我们通常认为，写得越少，跑得越快。但数据打破了这个迷思。

Haskell 和 OCaml 生成的最终代码行数（224行和 216行）是所有语言中最少的，甚至少于 Python 和 Ruby。然而，它们在生成时间上的表现却排在倒数（Haskell 耗时最长，达 174s）。

这表明，对于 AI 来说，函数式语言那种高度抽象、信息密度极大的代码，生成和推理的成本远高于像 Python、Go 那种稍微啰嗦但逻辑平铺直叙的“大白话”代码。浓缩的未必是精华，对于 LLM 来说，高度浓缩往往意味着更高的生成熵和更高的试错概率。

行业启示：我们需要重新思考 AI 时代的技术栈选型

面对这份详实的基准测试报告，无论你是 CTO 还是普通开发者，都必须开始重新审视未来的技术选型逻辑。

动态语言是快速原型的“绝对王者”

如果你正在启动一个新项目，或者需要用 AI Agent 快速验证一个业务流程，Python 和 TypeScript 是首选（报告中 JavaScript 表现优于 TS，但在实际工程中 TS 的综合权衡更佳）。

不要迷信“大型项目必须一开始就上强类型编译语言”。在需求快速变化的初期，让 AI 用动态语言狂飙突进，是获取业务反馈最高效的手段。

性能王者们的困境：Go 与 Rust 在 AI 时代掉队了吗？

看到测评数据，很多 Gopher 可能会感到失落：难道注重工程严谨性和系统级性能的静态语言，真的在 AI 时代掉队了吗？

结论并非如此悲观。我们需要明确一点：Agent 测评的速度，不等于软件最终运行的速度。

• 业务试错 vs 基础设施：AI Agent 目前最擅长、也最快速能完成的，是写“胶水逻辑”和“业务 CRUD”。在这些领域，Python 确实快。但当你的系统涉及到高并发、内存精细控制、或者需要打包为轻量级容器部署时，人类依然需要 Go。
• 容错的底线：在这场 600 次的庞大测试中，只有 Rust 和 Haskell 出现了最终测试失败，而 Go 保持了完美的 100% 成功率。这恰恰说明，Go 在“极度灵活（易幻觉）”与“极度严格（难生成）”之间，找到了一个非常微妙的平衡点。它可能不是 AI 写得最快的，但它一定是 AI 写出来最让人放心的系统级语言。

我们不应期待 AI Agent 能够像写 Python 脚本一样，如德芙般丝滑地生成出一个复杂的 Go 并发系统。但在 AI 给出的初稿之上，Go 语言极佳的可读性和统一的规范，将为人类工程师的最终审查（Code Review）节省巨大的精力。

小结：下一个十年的编程语言，长什么样？

ai-coding-lang-bench 给我们上了生动的一课。它揭示了当前 LLM 的偏好：它们喜欢有海量训练数据的、灵活的、不需要应对死板编译器的语言。

但我们必须认识到，这只是一份基于 2026 年初模型（Claude Opus 4.6）的快照。未来的 AI 编程语言形态，可能会朝着两个方向演进：

1. AI Native 语言的诞生：抛弃目前设计给人类阅读的语法，出现一种专门为了降低 LLM 生成 Token 成本、且天然抗幻觉的机器中间语言。
2. 现有静态语言的“Agent 友好化”编译模式：Go 和 Rust 可能会进化出一种特殊的编译模式。在这个模式下，编译器不仅是冷冰冰地报错，还能以结构化的、对 LLM 更友好的方式提供“修复建议”，从而大幅缩短 Agent 修复编译错误的反馈回路。

无论如何，浪潮已经来临。在 AI 主导代码生成的新时代，我们评价一门编程语言的标准，正在从“它对人类大脑是否友好”，悄然转变为“它对大模型推理是否友好”。

而在这场新赛道上，动态语言们，已经抢跑了。

本文核心数据与图表均来源于 GitHub 项目 mame/ai-coding-lang-bench。

你的 AI 编程初体验

看完这个排名，你是感到意外，还是早已感同身受？在你日常使用 AI 编程时，你觉得它写哪种语言最让你省心？你是否也曾为了修一个 AI 写的编译错误而陷入“死循环”？

欢迎在评论区分享你的“AI 协作”红黑榜！

“语言的严格性正在变成 AI 的摩擦力？在 AI 时代，掌握一套能驱动 Agent 自动化、自修复的‘工作流’比死磕语法更重要。我的新专栏 《AI原生开发工作流实战》 将教你如何利用 Claude Code 结合 Spec 驱动开发，构建真正高产出的‘软件工厂’。”

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/10/30/type-theory-intro-for-gopher

大家好，我是Tony Bai。

你是否曾有过这样的经历：在浏览一个关于 Go 泛型或接口设计的 GitHub issue 或技术提案时，评论区里的大佬们突然开始讨论 “Sum Type”、“Product Type”、“Parametric Polymorphism” 或是 “Higher-Kinded Types”。一瞬间，你感觉自己仿佛闯入了一个学术研讨会，这些看似熟悉又陌生的词汇让你一头雾水，只想默默关掉页面。

作为一名务实的 Gopher，我们习惯于用具体的代码和设计模式来思考问题。我们关心的是接口的解耦能力、struct 的组合性、goroutine 的并发效率。这些学院派的类型理论术语，似乎离我们的日常工作很遥远。

然而，事实并非如此。这些术语并非象牙塔里的空谈，它们是计算机科学家们经过几十年沉淀，用来精确描述和分类编程语言核心特性的“通用语言”。理解它们，就像给一位经验丰富的工匠配上了一套精准的图纸和测量工具。它能让你：

1. 更深刻地理解 Go 的设计哲学：为什么 Go 的接口如此强大？为什么 Go 1.18之前 长期以来没有泛型？为什么 int 和 int32 不能直接相加？这些背后都有类型理论的影子。
2. 更清晰地沟通技术方案：当你能用“Product Type”来描述 struct，用“Sum Type”的思想来解释接口的用途时，你的技术沟通会变得更加精确和高效。
3. 看懂高阶的技术讨论：无论是 Go 语言的未来演进，还是与其他语言（如 Rust, Haskell, Scala）的对比，这些术语都是绕不开的基石。

本文的灵感来源于阅读Simon Thompson教授所著《Type Theory & Functional Programming》一书时的感悟，但我们的目标并非成为类型理论的研究者。恰恰相反，我们的目标是做一个“翻译者”，将这些核心的理论概念，用我们最熟悉的 Go 语言特性和代码示例进行“转码”，彻底拉通学术殿堂与工程实践之间的鸿沟。

准备好了吗？让我们一起告别懵圈，开启这段实战派 Gopher 的类型理论入门之旅。

地基与框架 —— 到底什么是“类型系统”？

在深入具体的类型之前，我们首先需要建立一个宏观的框架。一个编程语言的类型系统 (Type System)，从学术角度来说，是一套规则集合，它为程序中的每个值（value）、变量（variable）和表达式（expression）都关联一个“类型”属性。

它的核心目的非常单纯且强大：在程序造成危害（比如运行时崩溃）之前，通过检查类型的合法性来预防错误。正如 Go 的领军人物 Rob Pike 所言：类型系统旨在“让非法的状态无法表示”。

为了系统性地理解它，我们可以从以下几个关键维度来对其进行分类和审视。

类型检查的时机：编译时 vs. 运行时 (Static vs. Dynamic)

这是对类型系统最基本、最重要的划分。

静态类型 (Statically Typed)

定义：类型检查在编译时完成。编译器会像一位严谨的图书管理员，在程序运行前，通读你的全部代码，检查每一个变量的赋值、每一次函数调用，确保类型在所有地方都严格匹配。如果发现问题，程序将无法通过编译。

优点：
* 早期错误发现：绝大多数类型相关的 bug 在开发阶段就被扼杀在摇篮里。
* 更高的性能：编译器确切地知道每个变量的类型和内存布局，可以生成高度优化的机器码。运行时无需再花费时间去检查类型。
* 更好的工具支持和可维护性：类型本身就是最可靠的文档。IDE 能提供精准的自动补全、代码导航和安全的重构。

Go 是一门不折不扣的静态类型语言。 它的编译器是你的第一道防线。

package main

func main() {
    var i int
    // 下面这行代码会导致编译失败，而不是运行时错误
    i = "hello"
}

// go build -> ./main.go:6:4: cannot use "hello" (type untyped string) as type int in assignment

动态类型 (Dynamically Typed)

定义：类型检查发生在运行时。变量本身没有固定的类型，它可以随时指向任何类型的值。只有当代码执行到某一行，需要对一个值进行特定操作时，解释器才会检查这个值的类型是否支持该操作。

代表语言：Python, JavaScript, Ruby。

Go 中的“动态”一面：虽然 Go 语言本身是静态的，但它通过 interface{} (自 Go 1.18 起的别名 any) 提供了一种强大的机制来处理不确定的类型，这在行为上模拟了动态类型的灵活性。

一个接口值可以看作一个“箱子”，它包含了两部分信息：值的动态类型（dynamic type）和动态值（dynamic value）。

package main
import "fmt"

func main() {
    // data 的静态类型是 any，它可以持有任何类型的值
    var data any

    data = "hello, world" // 编译通过，data 的动态类型是 string
    printValue(data)

    data = 42 // 编译通过，data 的动态类型是 int
    printValue(data)

    data = true // 编译通过，data 的动态类型是 bool
    printValue(data)
}

func printValue(v any) {
    // 使用类型断言(type assertion)或类型选择(type switch)在运行时检查动态类型
    switch val := v.(type) {
    case string:
        fmt.Printf("It's a string: %s\n", val)
    case int:
        fmt.Printf("It's an integer: %d\n", val)
    default:
        fmt.Printf("It's some other type: %T\n", val)
    }
}

这种机制是 Go 实现通用数据结构和处理 JSON 等非结构化数据的基石，但代价是放弃了部分编译时的类型安全，并将检查推迟到了运行时。

类型的严格程度：强类型 vs. 弱类型 (Strong vs. Weak)

这个维度的划分标准在学术界略有争议，但通常用来描述一门语言对于不同类型间隐式转换的容忍度。

强类型 (Strongly Typed)

定义：语言严格限制不同类型之间的隐式转换。当一个操作需要特定类型时，你必须提供该类型的值。如果类型不匹配，要么编译失败，要么运行时报错，语言本身不会“自作主张”地进行不安全的转换。

Go 的类型系统是出了名的“强硬”。

package main

import "strconv"

func main() {
    var a int = 10
    var b float64 = 5.5

    // 编译错误：不同数值类型之间不能直接运算
    // c := a + b // invalid operation: a + b (mismatched types int and float64)

    // 必须进行显式类型转换
    c := float64(a) + b // 正确

    var i int32 = 100
    var j int64 = 200

    // 即使是不同位数的整型，也必须显式转换
    // k := i + j // invalid operation: i + j (mismatched types int32 and int64)
}

这种严格性杜绝了许多在 C/C++ 或 JavaScript 中常见的、因隐式转换导致的难以察觉的 bug，让代码行为更加可预测。

弱类型 (Weakly Typed)

定义：语言倾向于在操作中自动进行类型转换，以“尽力”让程序继续运行。

代表语言：JavaScript 是典型代表，’5′ + 1 会得到字符串 ’51′，而 ’5′ – 1 会得到数字 4。这种灵活性有时很方便，但也是 bug 的温床。

类型的等价性判断：名义类型 vs. 结构类型 (Nominal vs. Structural)

这是判断“类型 A 和类型 B 是否相同（或兼容）”的规则，也是理解 Go 接口的关键。

名义类型 (Nominal Typing)

定义：类型是否等价，取决于它们的名称。即使两个类型拥有完全相同的底层结构和字段，只要它们的类型名称不同，它们就是两个完全不同的、不兼容的类型。

Go 的核心类型（structs, named basic types）遵循名义类型系统。

package main
import "fmt"

type UserID int
type ProductID int

type Point struct {
    X, Y int
}

type Vector struct {
    X, Y int
}

func main() {
    var uid UserID = 123
    var pid ProductID = 123

    // 编译错误：尽管底层都是 int，但类型名称不同
    // if uid == pid { ... } // invalid operation: uid == pid (mismatched types UserID and ProductID)

    p := Point{1, 2}
    v := Vector{1, 2}

    // 编译错误：尽管结构完全相同，但类型名称不同
    // if p == v { ... } // invalid operation: p == v (mismatched types Point and Vector)
}

名义类型提供了非常强的意图保证。UserID 就是 UserID，它承载的业务含义与 ProductID 完全不同，编译器强制你区分它们，从而避免了将用户 ID 误用为产品 ID 的逻辑错误。

结构类型 (Structural Typing)

定义：类型是否兼容，取决于它们的结构或“形状”（它们有哪些字段、哪些方法）。只要结构满足要求，类型就是兼容的，这与它们的名称无关。这通常被称为“鸭子类型”（Duck Typing）——“如果它走起来像鸭子，叫起来也像鸭子，那么它就是一只鸭子。”

Go 的体现：Go 的 interface 系统是纯粹的结构类型系统。

package main
import "fmt"

// 定义一个“会叫的”接口
type Quacker interface {
    Quack() string
}

// Duck 类型，它有一个 Quack 方法
type Duck struct{}
func (d Duck) Quack() string {
    return "Quack!"
}

// Person 类型，它也有一个 Quack 方法
type Person struct{}
func (p Person) Quack() string {
    return "I'm quacking like a duck!"
}

// 这个函数只关心传入的值是否满足 Quacker 接口的“结构”
func MakeItQuack(q Quacker) {
    fmt.Println(q.Quack())
}

func main() {
    var d Duck
    var p Person

    // Duck 和 Person 都没有显式声明 "implements Quacker"
    // 但因为它们都有 Quack() string 方法，所以它们都满足 Quacker 接口
    MakeItQuack(d) // 输出: Quack!
    MakeItQuack(p) // 输出: I'm quacking like a duck!
}

Go 的这一设计堪称神来之笔：在一个整体为名义类型的静态语言中，通过接口开辟了一块结构类型的区域，从而在不牺牲类型安全的前提下，获得了动态语言般的灵活性和强大的解耦能力。 你可以在不修改第三方库代码的情况下，让自己的类型去实现它的接口。

Go 类型系统的定位

综合以上维度，我们可以给 Go 的类型系统下一个精准的定义：

Go 是一门静态、强类型的语言。它主要采用名义类型系统来保证代码的严谨性和意图明确性，同时通过接口这一特性，创造性地引入了结构类型系统，以实现灵活、非侵入式的多态。

现在，我们已经搭建好了理解类型系统的宏观框架。接下来，让我们深入到类型的“原子世界”，看看那些让 Gopher 们“懵圈”的术语，在 Go 中究竟是什么模样。

类型的“和”与“积” —— Go 世界的 Sum & Product Type

在类型理论中，最基本的两种类型组合方式是“积”与“和”。它们就像算术中的乘法和加法，是构建更复杂类型的基础。

Product Type (积类型)：A and B

学术定义：一个积类型（Product Type）的值由多个其他类型的值同时组成。如果一个类型 P 是类型 A 和类型 B 的积类型，那么 P 的一个值会同时包含一个 A 类型的值和一个 B 类型的值。

这听起来很熟悉，对吗？

Go 的实现：struct

struct 是 Go 对积类型的直接且完美的实现。

// Person 类型是 string 和 int 的积类型
type Person struct {
    Name string // 包含一个 string
    Age  int    // 和一个 int
}

// p1 这个值同时持有一个 string "Alice" 和一个 int 30
var p1 Person = Person{Name: "Alice", Age: 30}

学术上，积类型最简单的形式是元组 (Tuple)，例如 (string, int)。Go 不支持原生的元组语法，但 struct 在功能上是更强大的、带命名字段的元组。你甚至可以通过多返回值来模拟元组的使用：

func getPerson() (string, int) {
    return "Bob", 42
}

// name 和 age 在这里就像一个临时的元组
name, age := getPerson()

所以，下次当你在讨论中听到 Product Type，你就可以自信地在脑海里将它替换为：“哦，就是 struct 这种东西。”

Sum Type (和类型)：A or B

学术定义：一个和类型（Sum Type），也叫可辨识联合 (Discriminated Union) 或变体 (Variant)，它的值在任意时刻只能是几种可能性中的一种。如果一个类型 S 是类型 A 和类型 B 的和类型，那么 S 的一个值要么是一个 A 类型的值，要么是一个 B 类型的值，绝不可能同时是两者。

很多现代语言，如 Rust、Swift、Haskell，都有原生语法来支持和类型：

// Rust 中的 enum 就是一个和类型
enum Result<T, E> {
    Ok(T),    // 要么是成功，里面包含一个 T 类型的值
    Err(E),   // 要么是失败，里面包含一个 E 类型的值
}

Go 语言没有提供上述那样的原生和类型语法。这是 Go 设计者在语言复杂性上做出的一个明确权衡。但是，Go 开发者每天都在使用和类型的思想，只是我们用的是另一种工具——接口。

一个接口类型定义了一个方法的集合。任何实现了这些方法的类型，都可以被看作是这个接口类型集合中的一员。因此，一个接口类型的变量，可以持有任何一个满足其要求的具体类型的值。这正是“A 或 B 或 C…”的核心思想。

让我们用一个经典的例子来具象化这个概念：一个图形应用需要处理不同的形状。

package main
import "math"

// Shape 接口定义了一个“和类型”，它可以是任何能计算面积的东西。
// 它可以是 Circle，或者是 Rectangle，或者是未来我们定义的任何其他形状。
type Shape interface {
    Area() float64
}

// --- 可能性 1: Circle ---
type Circle struct {
    Radius float64
}
func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

// --- 可能性 2: Rectangle ---
type Rectangle struct {
    Width, Height float64
}
func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

// 这个函数接受一个 Shape 类型的值。
// 它不关心这个值到底是 Circle 还是 Rectangle，只关心它能调用 Area() 方法。
func PrintArea(s Shape) {
    // 这时，变量 s 的值可能是 Circle 或 Rectangle 之一
    fmt.Printf("Area of %T is %0.2f\n", s, s.Area())
}

func main() {
    c := Circle{Radius: 5}
    r := Rectangle{Width: 4, Height: 3}

    PrintArea(c) // 输出: Area of main.Circle is 78.54
    PrintArea(r) // 输出: Area of main.Rectangle is 12.00
}

在这个例子里，Shape 接口扮演了和类型的角色。一个 Shape 变量的值，在任何时刻，要么是一个 Circle，要么是一个 Rectangle。

如何“辨识”具体的类型？—— type switch

和类型的一个关键特性是“可辨识”（Discriminated）。这意味着我们必须有办法知道当前的值到底是哪个具体的类型。在 Go 中，我们使用 type switch 来实现这一点。

func PrintShapeDetails(s Shape) {
    fmt.Printf("Shape details for %T:\n", s)
    switch shape := s.(type) {
    case Circle:
        // 在这个 case 分支里，编译器知道 shape 的类型是 Circle
        fmt.Printf("  It's a circle with radius %.2f\n", shape.Radius)
    case Rectangle:
        // 在这个 case 分支里，编译器知道 shape 的类型是 Rectangle
        fmt.Printf("  It's a rectangle with width %.2f and height %.2f\n", shape.Width, shape.Height)
    default:
        fmt.Println("  It's an unknown shape.")
    }
}

type switch 是处理和类型值时的“模式匹配”，它安全地拆开接口这个“箱子”，并根据里面的动态类型执行相应的逻辑。

模拟的代价：开放性与编译时检查的缺失

Go 的接口模拟与原生和类型有一个本质区别：接口是开放的，而原生和类型通常是封闭的。

• 封闭性 (Sealed/Closed)：在 Rust 的例子中，Result只能是 Ok(T)中的T 或 Err(E)中的E，编译器知道所有可能性。如果你在 match（类似 switch）时漏掉了一种情况，编译器会报错。
• 开放性 (Open)：在 Go 的例子中，任何包、任何地方都可以定义一个新的类型（比如 Triangle），只要它实现了 Area() 方法，它就可以被赋值给 Shape 变量。这意味着编译器永远无法保证你的 type switch 处理了所有情况，因此 default 分支变得至关重要。

为了在 Go 中模拟一个更“封闭”的和类型，有时会使用一种技巧：在接口中定义一个私有方法。

type Shape interface {
    Area() float64
    isShape() // 私有方法
}

由于私有方法 isShape 只能在同一个包内被实现，这实际上就将 Shape 接口的实现者限制在了当前包内，从而模拟了一个封闭的和类型。这在 Go 标准库中（例如 net/url.go 中的 addr 接口）时有应用。

所以，下次当你看到 Sum Type 这个术语，你的脑海中应该浮现出这样的映射：

“哦，这是指一个值在多个类型中‘非此即彼’的概念。Go 没有原生支持它，但我们通过 interface 和 type switch 的组合，在工程实践中出色地模拟了它的核心思想。”

抽象的力量 —— Go 中的函数与多态

类型系统不仅用于组合数据，更强大的能力在于抽象行为。这主要涉及到函数类型和多态。

函数类型 (Function Types)

学术定义：从类型 A 到类型 B 的一个映射，记作 A -> B。在函数式编程和类型理论中，函数本身就是一种可以被传递、存储和返回的值，即“一等公民”。

Go 的实现：Go 完全支持一等公民函数。我们可以定义函数类型，这在 Go 代码中非常常见。

package main
import "fmt"

// 定义一个函数类型 Operator，它接受两个 int，返回一个 int
type Operator func(int, int) int

func add(a, b int) int {
    return a + b
}

func multiply(a, b int) int {
    return a * b
}

// calculate 函数接受一个 Operator 类型的函数作为参数
func calculate(a, b int, op Operator) {
    result := op(a, b)
    fmt.Printf("Result is: %d\n", result)
}

func main() {
    calculate(10, 5, add)      // 输出: Result is: 15
    calculate(10, 5, multiply) // 输出: Result is: 50
}

HTTP 中间件、策略模式等诸多设计模式在 Go 中都大量利用了函数类型。

多态 (Polymorphism)

“Polymorphism”源于希腊语，意为“多种形态”。在编程中，它指代一段代码可以处理不同类型的值的能力。类型理论通常将其分为几种。

参数多态 (Parametric Polymorphism)

学术定义：编写的代码其逻辑对于操作的值的具体类型是通用的、不相关的。函数或数据结构可以被一个或多个类型参数化。例如，一个反转列表的函数，其逻辑（交换头尾元素）与列表里存的是整数、字符串还是用户自定义结构完全无关。

Go 的实现：泛型 (Generics, Go 1.18+)

在 Go 1.18 之前，Gopher 们只能通过 interface{} 和反射来模拟参数多态，但这牺牲了类型安全和性能。泛型的引入，为 Go 提供了实现参数多态的“正统”方式。

package main
import "fmt"

// 这个函数的逻辑对任何类型 T 都是一样的
// T 是一个类型参数
func Reverse[T any](s []T) {
    for i, j := 0, len(s)-1; i < j; i, j = i+1, j-1 {
        s[i], s[j] = s[j], s[i]
    }
}

func main() {
    intSlice := []int{1, 2, 3, 4}
    Reverse(intSlice)
    fmt.Println(intSlice) // 输出: [4 3 2 1]

    stringSlice := []string{"a", "b", "c"}
    Reverse(stringSlice)
    fmt.Println(stringSlice) // 输出: [c b a]
}

当你听到 Parametric Polymorphism，你就可以直接联想到 Go 的泛型。

子类型多态 (Subtype Polymorphism)

学术定义：一个函数或操作可以作用于某个类型 T，同时也能作用于 T 的所有子类型。例如，一个处理 Animal 的函数，应该也能处理 Dog 和 Cat，因为 Dog 和 Cat 都是 Animal 的子类型。

Go 的实现：接口 (Interfaces)

我们又回到了接口！在 Go 的世界里，子类型的概念正是通过接口来实现的。如果类型 T 实现了接口 I，那么 T 就可以被看作是 I 的一个“子类型”。

更准确地说，Go 实现的是结构化子类型 (Structural Subtyping)。

package main
import (
    "bytes"
    "fmt"
    "io"
    "os"
)

// 这个函数接受任何满足 io.Reader 接口的类型
// os.File 是 io.Reader 的一个“子类型”
// bytes.Buffer 也是 io.Reader 的一个“子类型”
func ReadAndPrint(r io.Reader) {
    data, err := io.ReadAll(r)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))
}

func main() {
    // 从文件读取
    file, _ := os.Open("test.txt")
    defer file.Close()
    ReadAndPrint(file)

    // 从内存中的 buffer 读取
    buffer := bytes.NewBufferString("Hello from buffer!")
    ReadAndPrint(buffer)
}

ReadAndPrint 函数体现了子类型多态：它被编写用来处理 io.Reader 这一通用类型，但实际上它可以无缝处理 os.File、bytes.Buffer 以及任何其他未来可能出现的、满足 io.Reader 结构的类型。

Ad-hoc 多态 (Ad-hoc Polymorphism)

学术定义：也称为重载 (Overloading)。同一个函数名可以有多个不同的实现，具体调用哪个实现取决于参数的类型。例如，add(int, int) 和 add(string, string) 是两个不同的函数。

Go 不支持函数重载。Go 的哲学是“显式优于隐式”，函数签名（包括函数名、参数类型和返回值类型）是唯一的。

理论的边界 —— Go 类型系统“做不到”的事

理解一门语言，不仅要知道它能做什么，也要知道它的边界在哪里，以及为什么会有这些边界。这通常是设计者在“表达力”与“简洁性”之间做出权衡的结果。

依赖类型 (Dependent Types)

学术定义：一种高级的类型系统特性，允许类型依赖于值。这意味着类型可以由程序中的常规变量来参数化。

经典例子：定义一个“长度为 n 的向量”类型 Vector(n)。这样，Vector(3) 和 Vector(4) 就是两个完全不同的类型。编译器可以静态地保证你不会把一个长度为 3 的向量赋值给一个长度为 4 的向量变量，或者保证矩阵乘法的维度匹配。

// 伪代码，Go 并不支持
func dotProduct(n: int, v1: Vector(n), v2: Vector(n)) -> float64 {
    // ...
}

var vec3 Vector(3)
var vec4 Vector(4)
dotProduct(3, vec3, vec4) // 编译错误！vec4 的长度不是 3

Go完全不支持依赖类型。Go 的类型系统在编译时工作，而像 n 这样的值通常在运行时才知道。将运行时信息混入编译时类型检查会极大地增加语言和编译器的复杂性。Go 选择了简洁，将这类检查（如切片长度）的责任交给了程序员，通过 len() 函数和运行时 panic 来保障。

值得一提的是，Go 的数组类型 [N]T 具有依赖类型的“影子”。例如，[3]int 和 [4]int 是不同的类型，因为它们的类型定义依赖于值 3 和 4。但这并非真正的依赖类型，因为数组的长度 N 必须是一个编译时常量，而不能是一个运行时变量。这个限制正是 Go 的数组与依赖类型的本质区别，也是 Go 在追求更强类型安全与保持语言简洁性之间做出的一种工程权衡。

高阶类型 (Higher-Kinded Types, HKTs)

这是一个在函数式编程和高级类型系统讨论中频繁出现的术语，也是理解 Go 泛型设计边界的关键所在。乍一听可能有些吓人，但我们可以通过类比来轻松理解它。

通俗解释：类型的“阶”

想象一下我们熟悉的函数：

• 一阶函数：操作“值”。例如，func add(a, b int) int 接受 int 值，返回 int 值。
• 高阶函数：操作“函数”。例如，func apply(f func(int) int, v int) int 接受一个函数 f 作为参数。

现在，我们把这个概念“提升”到类型层面：

• 一阶类型 (或称普通类型)：就是一个具体的类型，比如 int, string, struct{}。在类型理论中，它们的“种类”(Kind) 被记为 *。

• 高阶类型 (Higher-Kinded Types)：不是一个完整的类型，而是一个“类型的模板”或“类型构造器”(Type Constructor)。它接受一个或多个普通类型作为参数，然后“构造”出一个新的普通类型。

  • []T 就是一个类型构造器。[] 本身不是类型，你必须给它一个类型（如 int），才能得到一个完整的类型 []int。它的“种类”可以记为 * -> * (接受一个类型，返回一个类型)。
  • 同理，map[K]V 也是一个类型构造器，它的“种类”是 * -> * -> * (接受两个类型，返回一个类型)。
  • chan T 也是 * -> *。

高阶类型系统，就是指一门语言的泛型系统能够对类型构造器本身进行抽象的能力。换句话说，泛型参数不仅可以是 T（代表一个普通类型），还可以是 F（代表一个类型构造器，如 [] 或 chan）。

Go 的现状：不支持高阶类型

Go 的泛型系统被设计为只处理一阶类型。这意味着 Go 的类型参数 [T any] 只能代表一个完整的类型。

• T 可以是 int。
• T 也可以是 []int。
• 但 T 不能是 [] 本身。

让我们通过一个经典的 Map 函数的例子来具体说明这一点。我们的目标是写一个通用的 Map 函数，它能将一个容器里的所有元素通过一个函数进行转换，并返回一个包含新元素的同类容器。

Go 能做到的：为每种容器编写独立的泛型函数

由于 Go 不支持 HKTs，我们必须为 slice、channel 或其他任何我们想支持的容器类型，分别编写一个泛型 Map 函数。

// 为 slice 实现的 Map
func SliceMap[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

// 为 channel 实现的 Map (简化版)
func ChanMap[T, U any](ch <-chan T, f func(T) U) <-chan U {
    result := make(chan U)
    go func() {
        defer close(result)
        for v := range ch {
            result <- f(v)
        }
    }()
    return result
}

注意，SliceMap 和 ChanMap 的核心逻辑思想是一致的，但因为容器的操作方式（创建、遍历、添加元素）不同，且 Go 无法抽象“容器”这个概念，我们不得不重复编写。

Go 做不到的：一个统一所有容器的 Map 函数（伪代码）

如果 Go 支持高阶类型，我们就可以梦想编写一个 UniversalMap 函数。下面的代码使用了 Go 的语法风格，但它在 Go 中是完全无法编译的，它仅仅是为了展示 HKTs 的思想。

// ----------------------------------------------------
// !! 警告：以下是 HKTs 思想的伪代码，无法在 Go 中编译 !!
// ----------------------------------------------------

// 这里的 type F[T] any 是一种虚构的语法，
// 意在声明“F 是一个接受单一类型参数的类型构造器”。
func UniversalMap[type F[T] any, T, U any](container F[T], f func(T) U) F[U] {
    // 这段函数体在 Go 中是无法实现的，因为：
    // 1. 如何创建一个 F[U] 类型的新容器？make(F[U]) 语法无效。
    // 2. 如何遍历一个抽象的 F[T] 容器？range 关键字只认识内置类型。
    // 3. 如何向 F[U] 中添加一个元素？是 append 还是 <- 发送？

    panic("This is pseudo-code demonstrating what HKTs would enable.")
}

func main() {
    ints := []int{1, 2, 3}
    intChan := make(chan int)

    // 在一个支持 HKTs 的理想世界里，我们可以这样调用：
    // strings := UniversalMap(ints, func(i int) string { ... })      // 期望返回 []string
    // stringChan := UniversalMap(intChan, func(i int) string { ... }) // 期望返回 chan string
}

这段伪代码清晰地揭示了 Go 泛型的边界：

1. 语法限制：Go 没有定义 [type F[T] any] 这样的语法来表示“一个类型构造器”作为类型参数。
2. 实现限制：即使语法允许，Go 缺乏一个通用的接口来描述“容器”的基本操作（如 map, flatMap 等）。支持 HKTs 的语言（如 Haskell, Scala）通常会提供一套名为 Functor, Monad 的“类型类”或“特质”(traits) 来定义这些通用操作，程序员可以为自己的容器类型（比如自定义的 Tree[T]）实现这些接口。

为什么 Go 选择不支持 HKTs？

这是一个深思熟虑的设计决策。Go 语言的核心哲学之一是简洁性和可读性。高阶类型的概念虽然强大，但它引入了更高层次的抽象，极大地增加了语言的复杂性和程序员的心智负担。对于 Go 团队来说，为 slice 和 chan 等几种常见类型编写独立的泛型函数，这种适度的代码重复，相比于引入整个 HKTs 体系所带来的复杂性，是一个更值得接受的权衡。

所以，当你听到 Higher-Kinded Types，你可以这样理解：“它是一种更强大的泛型，可以对像 []T 中的 [] 这样的‘类型模板’本身进行参数化，但 Go 为了保持简洁而没有支持它。因此在 Go 中，我们需要为不同的容器类型（如 slice, channel）编写各自的泛型工具函数。”

小结：从“懵圈”到“通透”

我们从令人困惑的 GitHub issue 讨论出发，踏上了一段连接类型理论与 Go 语言实践的旅程。现在，让我们回顾一下我们的“翻译”成果，将那些抽象的术语牢牢地锚定在 Go 的具体实现上：

• 类型系统框架：我们确立了 Go 的定位——一个静态、强类型的系统，它以名义类型为基础保证代码的严谨性，同时通过接口这一卓越设计，巧妙地融合了结构类型的灵活性。

• Product Type (积类型)：这个概念不再神秘，它就是我们日常工作中构建复合数据的基石——struct。

• Sum Type (和类型)：我们揭示了 Go 是如何通过接口和type switch 这一组合拳，优雅地模拟出和类型的核心思想（“A 或 B”）。我们最熟悉的 error 接口，便是这一思想在 Go 生态中最无处不在的体现。

• Parametric Polymorphism (参数多态)：我们看到，Go 1.18+ 的泛型为其提供了原生的、类型安全的支持，让我们得以编写出与具体类型无关的通用算法和数据结构。

• Subtype Polymorphism (子类型多态)：这再次指向了 Go 接口的强大之处。它基于结构化子类型，构建了一个非侵入式、高度解耦的多态模型，这是 Go 强大组合能力的核心源泉。

• 理论的边界 (Dependent Types & HKTs)：我们不仅理解了这些高级特性是什么，更重要的是，通过具体的伪代码示例，我们清晰地看到了 Go 泛型的局限性——它只能参数化完整的类型，而无法抽象类型构造器（如 [] 或 chan）。我们明白了，这些“做不到”并非语言的缺陷，而是 Go 团队在追求简洁性、可读性和工程实用性方面做出的深思熟虑的设计权衡。

掌握这些术语，并不仅仅是为了在技术讨论中显得“专业”。更重要的是，它为我们提供了一个更深刻、更系统的视角来审视我们每天使用的工具。它解释了 Go 为什么是现在这个样子，它的优势在哪里，它的取舍又在哪里。

希望这篇文章能成为你工具箱里的一件利器。当你下一次再遇到那些“学院派”术语时，你将不再“懵圈”，而是能够会心一笑，轻松地将它们映射到你熟悉的 Go 世界中，从而更加自信地去创造、去构建、去解决实际的工程问题。

毕竟，对于实战派 Gopher 而言，任何理论的最终价值，都在于它能否帮助我们写出更好、更稳健、更易于维护的代码。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2024/08/11/understand-functional-programming-in-go

一个孩子要尝试10次、20次才肯接受一种新的食物，我们接受一种新的范式，大概不会比这个简单。– 郭晓刚 《函数式编程思维》译者

函数式编程(Functional Programming, 简称fp)是一种编程范式，与命令式编程(Imperative Programming)、面向对象编程(OOP)、泛型编程(Generics Programming)、逻辑编程(logic Programming)等是一类的概念。

注：尽管面向对象范式引入了新的编程思想和技术，但它本质上与命令式编程一样，都关注程序的状态和如何通过改变状态来控制程序的执行流程，因此，OOP仍然属于命令式编程的一个分支。OOP可以看作是命令式编程的一种扩展和补充，它增强了代码的模块化、复用性和可维护性。在接下来，我会统一使用命令式编程范式来指代它们。

但几十年的编程语言的演进和实践已经证明：函数式编程并非银弹，它有优势，更有不足。从编程社区的实际反映来看，纯函数式编程语言(比如：CLisp、Haskell、Scala、Clojure、Erlang等)始终处于小众地位。此外，即便很多主流命令式编程语言在近些年融入了一些函数式编程的语法特性，采用函数式风格的代码依旧比例极低，且不易被广泛接受。许多程序员在面对复杂的状态管理和副作用时，依然倾向于使用传统的命令式编程风格（包括OOP)。。

注：Go就原生提供了一些支持函数式范式编程的语法特性，比如：函数是一等公民(first-class)、高阶函数、闭包、函数迭代器以及泛型等。

造成这种局面的原因众说纷纭，但我认为有如下几个：

首先从人类这个物种的大脑的认知和思维方式来看，命令式编程更接近于人类的自然思维方式，其逻辑与人类解决问题时的逻辑思维相似，即都是以步骤的形式理解问题，且有明确的控制流：命令式语言的控制结构（如条件语句、选择语句和循环）使得程序的执行路径清晰可见，符合人类的直觉理解，这也使得命令式语言更容易被人类大脑所掌握。

其次，命令式编程强调状态的变化，程序员可以直接看到和控制变量的变化，这与人类处理现实世界事物的方式相似。

在上面原因的驱使下，久而久之，程序员便形成习惯与传统，有了积淀，便可以促进命令式编程语言在教育和产业中的广泛应用，使得大多数程序员习惯于这种编程方式（间接挤压了函数式编程的使用空间）。进而使得命令式语言有更丰富的学习资源和社区支持，程序员也更容易找到帮助和示例。

也就是说，命令式编程范式占据主流的根本原因是人类的大脑本身就是命令式的，而不是函数式的。不过也有极少数大脑是函数式思维的，比如发明了TLA+这门形式化建模和验证语言的Leslie Lamport老先生。

那么问题来了！既然学习函数式编程思维是违反人类大脑直觉的，且较为困难，那为什么还是有很多人学习函数式编程思维，并在实际开发中应用函数式编程范式呢？关于这个问题，我们可以从两方面来看。

从主观上说，程序员经常有探索新技术和新范式的内在动力，这种好奇心驱使他们尝试函数式编程，也就是我们俗称的“玩腻了，尝尝鲜儿”。并且，许多程序员视学习函数式编程为一种智力挑战，一种来自舒适区之外的挑战，这种挑战能带来成就感和个人成长。此外，在竞争激烈的IT行业，掌握多种编程范式可以使得个人技能多样化，增加个人的职业竞争力。

从客观上看，函数式编程也确实能帮助程序员提高抽象思维和系统设计能力，这种能力的提升不仅限于函数式编程，还能应用到其他编程范式中。并且，函数式编程为程序员提供了一个新的解决问题的视角和方法，特别是在处理并发和并行计算、复杂数据转换和流处理方面。

学习函数式编程范式，并不是说抛弃命令式范式(或其他范式)，而是融合，从主流编程语言对函数式编程的语法特性的支持也可窥见这般。

那么，到底什么是函数式编程范式？它与命令式范式对比又有怎么样的差异与优劣呢？在这篇文章中，我就来说说我的体会，并辅以Go示例来帮助大家理解。

1. 思维差异：命令式编程 vs. 函数式编程

在看过很多函数式编程的资料后（见文后的参考资料一节），我问了自己一个问题：面对同一个实际的问题，用命令式编程范式和用函数式编程范式的核心思维差异在哪里？为此，我基于现实世界的一个典型问题模型(数据输入 -> 数据处理 -> 处理结果输出)，并根据自己的理解画了下面两幅图：

我们先来描述一下上面两幅图中的数据处理流程：

• 命令式编程：通过I/O操作获取数据，然后解码为自定义类型进行处理，再编码为自定义类型以便I/O操作输出。处理过程中使用函数、带方法的类型和控制流结构（如for、if、switch等）。

• 函数式编程：通过带有副作用的操作（如I/O操作）获取数据，然后解码数据放入通用数据结构（如列表、元组、映射）进行处理，再放入通用数据结构以便通过副作用操作输出。处理过程中会使用纯函数、高阶函数以及它们的函数组合。

基于上述流程的说明，我们可以看出两种范式核心关注点的差异：

• 命令式编程范式：更关注类型的封装、类型间的耦合关系、行为集合的抽象(接口)以及对数据在类型实例间的传递的显式控制(if/for/switch)。
• 函数式编程范式：弱化类型的概念，使用通用数据结构，专注于通过纯函数/高阶函数、不可变数据和函数组合来实现对数据的处理逻辑。“控制流”更加隐含，比如会通过递归、模式匹配和惰性求值等方式实现。建立专门的抽象来应对与真实世界交互时的带有副作用(side effect)的操作。

下面我们通过一个具体的问题来大致体会一下不同编程泛型在解决问题的实现上的思维差异。这个问题很简单：编写一个程序从input.txt文件中读取数字(每行一个数字)，将每个数字乘以2，然后将结果写入output.txt文件中。

我们先来用命令式编程范式实现：

// fp-in-go/double/go/main.go

// NumberData represents the input data
type NumberData struct {
    numbers []int
}

// ProcessedData represents the processed output data
type ProcessedData struct {
    numbers []int
}

// NewNumberData creates and returns a new NumberData instance
func NewNumberData() *NumberData {
    return &NumberData{numbers: []int{}}
}

// AddNumber adds a number to NumberData
func (nd *NumberData) AddNumber(num int) {
    nd.numbers = append(nd.numbers, num)
}

// Process doubles all numbers in NumberData and returns ProcessedData
func (nd *NumberData) Process() ProcessedData {
    processed := ProcessedData{numbers: make([]int, len(nd.numbers))}
    for i, num := range nd.numbers {
        processed.numbers[i] = num * 2
    }
    return processed
}

// FileProcessor handles file operations and data processing
type FileProcessor struct {
    inputFile  string
    outputFile string
}

// NewFileProcessor creates and returns a new FileProcessor instance
func NewFileProcessor(input, output string) *FileProcessor {
    return &FileProcessor{
        inputFile:  input,
        outputFile: output,
    }
}

// ReadAndDeserialize reads data from input file and deserializes it into NumberData
func (fp *FileProcessor) ReadAndDeserialize() (*NumberData, error) {
    file, err := os.Open(fp.inputFile)
    if err != nil {
        return nil, fmt.Errorf("error opening input file: %w", err)
    }
    defer file.Close()

    data := NewNumberData()
    scanner := bufio.NewScanner(file)
    for scanner.Scan() {
        num, err := strconv.Atoi(scanner.Text())
        if err != nil {
            return nil, fmt.Errorf("error converting to number: %w", err)
        }
        data.AddNumber(num)
    }

    if err := scanner.Err(); err != nil {
        return nil, fmt.Errorf("error reading input file: %w", err)
    }

    return data, nil
}

// SerializeAndWrite serializes ProcessedData and writes it to output file
func (fp *FileProcessor) SerializeAndWrite(data ProcessedData) error {
    file, err := os.Create(fp.outputFile)
    if err != nil {
        return fmt.Errorf("error creating output file: %w", err)
    }
    defer file.Close()

    writer := bufio.NewWriter(file)
    defer writer.Flush()

    for _, num := range data.numbers {
        _, err := writer.WriteString(fmt.Sprintf("%d\n", num))
        if err != nil {
            return fmt.Errorf("error writing to output file: %w", err)
        }
    }

    return nil
}

// Process orchestrates the entire data processing workflow
func (fp *FileProcessor) Process() error {
    // Read and deserialize input data
    inputData, err := fp.ReadAndDeserialize()
    if err != nil {
        return err
    }

    // Process data
    processedData := inputData.Process()

    // Serialize and write output data
    err = fp.SerializeAndWrite(processedData)
    if err != nil {
        return err
    }

    return nil
}

func main() {
    processor := NewFileProcessor("input.txt", "output.txt")
    if err := processor.Process(); err != nil {
        fmt.Fprintf(os.Stderr, "Error: %v\n", err)
        os.Exit(1)
    }
    fmt.Println("Processing completed successfully.")
}

这段代码十分容易理解，在这段代码中，我们建立了三个类型：NumberData、ProcessedData和FileProcessor。前两个分别代表解码后的输入数据和编码前的输出数据，FileProcessor则是封装了文件操作和数据处理的逻辑的自定义类型。这段代码将文件I/O、数据处理和主要流程控制分离到不同的方法中。在读取和写入过程中，数据经历了字符串 -> NumberData -> ProcessedData -> 字符串的转换过程，同时数据也是在不同类型的方法间传递和变换状态。

接下来我们再来看看函数式范式版本，Go虽然提供了一些函数式编程的基础支持，比如一等公民的函数、支持高阶函数、闭包等，但一些像monad、monoid等高级概念还需要手工实现。IBM开源了一个Go的函数式编程基础库fp-go，这里就借用fp-go的便利实现上面的同等功能，我们看看风格上有何不同：

// fp-in-go/double/fp-go/main.go

package main

import (
    "bufio"
    "fmt"
    "os"
    "strconv"
    "strings"

    "github.com/IBM/fp-go/either"
    "github.com/IBM/fp-go/ioeither"
)

// 读取文件内容
func readFile(filename string) ioeither.IOEither[error, string] {
    return ioeither.TryCatchError(func() (string, error) {
        content, err := os.ReadFile(filename)
        return string(content), err
    })
}

// 将字符串转换为数字列表
func parseNumbers(content string) either.Either[error, []int] {
    numbers := []int{}
    scanner := bufio.NewScanner(strings.NewReader(content))
    for scanner.Scan() {
        num, err := strconv.Atoi(scanner.Text())
        if err != nil {
            return either.Left[[]int](err)
        }
        numbers = append(numbers, num)
    }
    return either.Right[error](numbers)
}

// 将数字乘以2
func multiplyBy2(numbers []int) []int {
    result := make([]int, len(numbers))
    for i, num := range numbers {
        result[i] = num * 2
    }
    return result
}

// 将结果写入文件
func writeFile(filename string, content string) ioeither.IOEither[error, string] {
    return ioeither.TryCatchError(func() (string, error) {
        return "", os.WriteFile(filename, []byte(content), 0644)
    })
}

func main() {
    program := ioeither.Chain(func(content string) ioeither.IOEither[error, string] {
        return ioeither.FromEither(
            either.Chain(func(numbers []int) either.Either[error, string] {
                multiplied := multiplyBy2(numbers)
                result := []string{}
                for _, num := range multiplied {
                    result = append(result, strconv.Itoa(num))
                }
                return either.Of[error](strings.Join(result, "\n"))
            })(parseNumbers(content)),
        )
    })(readFile("input.txt"))

    program = ioeither.Chain(func(content string) ioeither.IOEither[error, string] {
        return writeFile("output.txt", content)
    })(program)

    result := program()
    err := either.ToError(result)

    if err != nil {
        fmt.Println("Program failed:", err)
    } else {
        fmt.Println("Program completed successfully")
    }
}

相对于前面使用命令式范式风格的代码，这段函数式范式的代码理解起来就要难上不少。

不过，这段代码很好地诠释了函数式编程中的函数组合理念，我们看到函数被当作值来传递和使用。例如，在ioeither.Chain中，我们传递了匿名函数作为参数，这体现了函数式编程中函数作为一等公民的概念。multiplyBy2函数是一个纯函数的例子，它没有副作用，对于相同的输入总是产生相同的输出。这种纯函数更容易测试和推理。

代码中最明显的函数组合例子是在main函数中，我们使用ioeither.Chain来组合多个函数操作。并且在这里，我们将文件读取、内容处理和文件写入操作串联在一起，形成一个更大的操作。而ioeither.Chain和either.Chain又都是高阶函数的例子，它们接受其他函数作为参数并返回新的函数。Either和IOEither类型也是函数式编程中用于错误处理的主流方式，允许我们以更函数式的方式处理错误，将错误处理集成到函数组合中。

很多人好奇如果用纯函数式编程语言实现这个示例会是什么样子的，下面我就贴一段Haskell语言的代码，大家简单了解一下，这里就不对代码进行解释了：

// fp-in-go/double/fp-haskell/Main.hs

import System.IO
import Control.Monad (when)
import Text.Read (readMaybe)
import Data.Maybe (catMaybes)

-- Define a custom type for the result
data DoubledNumbers = DoubledNumbers { doubledNumbers :: [Int] } deriving (Show)

-- Function to read numbers from a file
readNumbers :: FilePath -> IO (Either String [Int])
readNumbers filePath = do
    content <- readFile filePath
    let numbers = catMaybes (map readMaybe (lines content))
    return $ if null numbers
             then Left "No valid numbers found."
             else Right numbers

-- Function to write result to a file
writeResult :: FilePath -> DoubledNumbers -> IO (Either String ())
writeResult filePath result = do
    let resultString = unlines (map show (doubledNumbers result))
    writeFile filePath resultString
    return $ Right ()

-- Function to double the numbers
doubleNumbers :: [Int] -> DoubledNumbers
doubleNumbers numbers = DoubledNumbers { doubledNumbers = map (* 2) numbers }

main :: IO ()
main = do
    -- Read numbers from input.txt
    readResult <- readNumbers "input.txt"
    case readResult of
        Left err -> putStrLn $ "Error: " ++ err
        Right numbers -> do
            let result = doubleNumbers numbers
            -- Write result to output.txt
            writeResultResult <- writeResult "output.txt" result
            case writeResultResult of
                Left err -> putStrLn $ "Error: " ++ err
                Right () -> putStrLn "Successfully written the result to output.txt."

注：安装ghc后，执行ghc –make Main就可以将上面Main.hs编译为一个可执行程序。更多关于haskell编译器的信息可以到haskell官网查看。

从上面的示例我们大致也能感受到两种范式在思维层面的差异，正如Robert Martin在《函数式设计》一书中说道的那样：函数式程序更倾向于铺设调节数据流转换的管道结构，而可变的命令式程序更倾向于迭代地处理一个个类型对象。

我们很难在一个例子中体现出函数式编程的所有概念和思维特点，接下来，我们就来逐个说说函数式编程范式中的要素，你也可以对应前面的图中的内容，反复感受函数式编程的思维特点。

2. 函数式编程的要素

面向对象的编程通过封装不确定因素来使代码能被人理解，而函数式编程通过尽量减少不确定因素来使代码能被人理解。—— Michael Feathers 《修改代码的艺术》一书作者

函数式编程建立在几个核心要素之上，这些要素共同构成了函数式编程的基础。让我们逐一探讨这些要素。

2.1 纯函数 (Pure Functions)

纯函数是函数式编程的基石。一个纯函数具有以下特性:

• 对于相同的输入，总是产生相同的输出；
• 不会产生副作用(不会修改外部状态)；
• 不依赖外部状态。

例如，前面fp-go示例中的multiplyBy2就是一个纯函数:

func multiplyBy2(numbers []int) []int {
    result := make([]int, len(numbers))
    for i, num := range numbers {
        result[i] = num * 2
    }
    return result
}

这个函数总是为相同的输入返回相同的结果，并且不会修改任何外部状态。

2.2 不可变性 (Immutability)

Robert Martin在《函数式设计》一书为函数式编程下一个理想的定义：没有赋值语句的编程。实质是其强调了不可变性在函数式编程范式中的重要意义。在没有赋值语句的情况下，代码通常基于对原状态的计算而得到新的状态，而对原状态没有任何修改。

在Go语言中，由于不支持不可变变量(很多语言用val关键字来声明不可变变量，但Go并不支持)，我们通常通过复制对象来实现不可变性，这可以帮助我们避免状态变化带来的复杂性，但也因为复制而增加了内存开销和性能成本。

// 定义一个不可变的结构体
type Point struct {
    x, y int
}

// 创建一个新的 Point，模拟不可变性
func NewPoint(x, y int) Point {
    return Point{x, y}
}

// 移动Point的方法，返回一个新的Point
func (p Point) Move(dx, dy int) Point {
    return NewPoint(p.x+dx, p.y+dy)
}

2.3 高阶函数 (Higher-Order Functions)与函数组合(Function Composition)

Go语言的一个内置特性让它具备了使用函数式编程范式的前提，那就是在Go中，函数是一等公民。这意味着函数可以像其他类型变量一样，被赋值、传参和返回。

而接受其他函数作为参数或返回函数的函数，被称为高阶函数，这也是函数式编程的基石，如下面的applyOperation函数就是一个高阶函数：

func applyOperation(x int, operation func(int) int) int {
    return operation(x)
}

func double(x int) int {
    return x * 2
}

result := applyOperation(5, double) // 结果为10

而有了对高阶函数的支持，我们才能运用函数式思维中的核心思维：函数组合，来铺设调节数据流转换的管道结构：

// fp-in-go/high-order-func/main.go

package main

import (
    "fmt"
)

// 定义一个类型为函数的别名
type IntTransformer func(int) int

// 将多个转换函数组合成一个管道
func pipe(value int, transformers ...IntTransformer) int {
    for _, transformer := range transformers {
        value = transformer(value)
    }
    return value
}

// 定义一些转换函数
func addOne(x int) int {
    return x + 1
}

func square(x int) int {
    return x * x
}

func main() {
    // 使用管道处理数据
    result := pipe(3, addOne, square)
    fmt.Println("Result:", result) // 输出 Result: 16
}

这个示例中的pipe函数接受一个初始值和多个转换函数，并将其串联执行。main函数调用pipe函数，将addOne和square两个转换函数连接起来并执行输出结果。

前面那个使用fp-go编写的示例中，使用ioeither.Chain构建的program也是一个函数调用组合。

此外，链式调用也是一种在日常开发中常见的函数组合的使用形式，它融合了命令式的类型和函数式编程的函数组合，特别适用于集合类型数据的处理，通过链式调用，可以以更简洁和直观的方式进行数据转换和处理。下面是一个基于泛型实现的通用的链式调用(filter -> map -> reduce)的示例：

// fp-in-go/func-composition/main.go

package main

import "fmt"

// Collection 接口定义了通用的集合操作
type Collection[T any] interface {
    Filter(predicate func(T) bool) Collection[T]
    Map(transform func(T) T) Collection[T]
    Reduce(initialValue T, reducer func(T, T) T) T
}

// SliceCollection 是基于切片的集合实现
type SliceCollection[T any] struct {
    data []T
}

// NewSliceCollection 创建一个新的 SliceCollection
func NewSliceCollection[T any](data []T) *SliceCollection[T] {
    return &SliceCollection[T]{data: data}
}

// Filter 实现了 Collection 接口的 Filter 方法
func (sc *SliceCollection[T]) Filter(predicate func(T) bool) Collection[T] {
    result := make([]T, 0)
    for _, item := range sc.data {
        if predicate(item) {
            result = append(result, item)
        }
    }
    return &SliceCollection[T]{data: result}
}

// Map 实现了 Collection 接口的 Map 方法
func (sc *SliceCollection[T]) Map(transform func(T) T) Collection[T] {
    result := make([]T, len(sc.data))
    for i, item := range sc.data {
        result[i] = transform(item)
    }
    return &SliceCollection[T]{data: result}
}

// Reduce 实现了 Collection 接口的 Reduce 方法
func (sc *SliceCollection[T]) Reduce(initialValue T, reducer func(T, T) T) T {
    result := initialValue
    for _, item := range sc.data {
        result = reducer(result, item)
    }
    return result
}

// SetCollection 是基于 map 的集合实现
type SetCollection[T comparable] struct {
    data map[T]struct{}
}

// NewSetCollection 创建一个新的 SetCollection
func NewSetCollection[T comparable]() *SetCollection[T] {
    return &SetCollection[T]{data: make(map[T]struct{})}
}

// Add 向 SetCollection 添加元素
func (sc *SetCollection[T]) Add(item T) {
    sc.data[item] = struct{}{}
}

// Filter 实现了 Collection 接口的 Filter 方法
func (sc *SetCollection[T]) Filter(predicate func(T) bool) Collection[T] {
    result := NewSetCollection[T]()
    for item := range sc.data {
        if predicate(item) {
            result.Add(item)
        }
    }
    return result
}

// Map 实现了 Collection 接口的 Map 方法
func (sc *SetCollection[T]) Map(transform func(T) T) Collection[T] {
    result := NewSetCollection[T]()
    for item := range sc.data {
        result.Add(transform(item))
    }
    return result
}

// Reduce 实现了 Collection 接口的 Reduce 方法
func (sc *SetCollection[T]) Reduce(initialValue T, reducer func(T, T) T) T {
    result := initialValue
    for item := range sc.data {
        result = reducer(result, item)
    }
    return result
}

// ToSlice 实现了 Collection 接口的 ToSlice 方法
func (sc *SetCollection[T]) ToSlice() []T {
    result := make([]T, 0, len(sc.data))
    for item := range sc.data {
        result = append(result, item)
    }
    return result
}

func main() {
    // 使用 SliceCollection
    numbers := NewSliceCollection([]int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10})
    result := numbers.
        Filter(func(n int) bool { return n%2 == 0 }).
        Map(func(n int) int { return n * 2 }).
        Reduce(0, func(acc, n int) int { return acc + n })
    fmt.Println(result) // 输出: 60

    // 使用 SetCollection
    set := NewSetCollection[int]()
    for _, n := range []int{1, 2, 2, 3, 3, 3, 4, 5} {
        set.Add(n)
    }
    uniqueSum := set.
        Filter(func(n int) bool { return n > 2 }).
        Map(func(n int) int { return n * n }).
        Reduce(0, func(acc, n int) int { return acc + n })
    fmt.Println(uniqueSum) // 输出: 50 (3^2 + 4^2 + 5^2)
}

这段代码定义的泛型接口类型Collection包含三个方法：

• Filter：根据条件过滤集合中的元素。
• Map：对集合中的每个元素应用转换函数。
• Reduce：对集合中的元素进行归约操作，比如求和。

其中Filtre、Map都是返回集合自身，这样便允许实现Collection接口的集合类型(如上面的SetCollection和SliceCollection)使用链式调用，代码看起来也十分易于理解。

2.4 递归(Recursion)

递归是函数式编程中常用的控制结构，常用来替代循环。例如下面是计算阶乘的函数实现：

func factorial(n int) int {
    if n <= 1 {
        return 1
    }
    return n * factorial(n-1)
}

递归的优点十分明显，代码简洁，易于理解(相对于循环)，特别适合处理分解问题（如树结构、图遍历等）。但不足也很突出，比如可能导致栈溢出(尤其是对那些不支持尾递归优化的语言，比如Go)，特别是对于较大的输入。此外，由于每次递归调用都需要创建新栈帧，维护栈状态，递归会有额外的性能开销。调试递归函数也可能比循环更复杂，因为需要跟踪多个函数调用。

2.5 惰性求值 (Lazy Evaluation)

惰性求值是指延迟计算表达式的值，直到真正需要它的时候。这样可以避免不必要的计算并有效管理内存，特别是在处理大集合或无限集合时。下面是用惰性求值实现迭代集合元素的示例：

注：Go原生并不支持惰性求值的语法，但我们可以使用闭包来模拟。

// fp-in-go/lazy-evaluation/lazy-range/main.go

package main

import "fmt"

func lazyRange(start, end int) func() (int, bool) {
    current := start
    return func() (int, bool) {
        if current >= end {
            return 0, false
        }
        result := current
        current++
        return result, true
    }
}
func main() {
    next := lazyRange(1, 5)
    for {
        value, hasNext := next()
        if !hasNext {
            break
        }
        fmt.Println(value)
    }
}

我们看到这段代码通过惰性求值方式生成从1到4的数字，避免了预先生成整个范围的集合元素，节省了内存，并避免了不必要的计算。

我们再来看一个用惰性求值生成前N个斐波那契数列的示例：

// fp-in-go/lazy-evaluation/fibonacci/main.go

package main

import (
    "fmt"
)

// Fibonacci 返回一个生成无限斐波那契数列的函数
func Fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        a, b = b, a+b
        return a
    }
}

func main() {
    fib := Fibonacci()
    for i := 0; i < 10; i++ { // 打印前10个斐波那契数
        fmt.Println(fib())
    }
}

我们看到Fibonacci函数返回一个闭包，每次调用时生成下一个斐波那契数，这样我们在需要时生成下一个斐波那契数，而无需生成所有。

虽然函数式编程强调纯函数和不可变性，但在实际应用中，我们不可避免地需要处理副作用，如I/O操作、数据库交互等。接下来，我们就来看看在函数式编程范式中是如何处理带有副作用的操作的。

3. 函数式编程对副作用操作的处理

3.1 理解副作用

在函数式编程中，副作用是指函数或表达式在执行过程中对其周围环境产生的任何可观察到的变化。这些变化包括但不限于：

• 修改全局变量或静态局部变量
• 修改函数参数
• 执行I/O操作（读写文件、网络通信等）
• 抛出异常或错误
• 调用其他具有副作用的函数

副作用使得程序的行为变得难以预测和测试，因为函数的输出不仅依赖于其输入，还依赖于程序的状态和外部环境。函数式编程通过最小化副作用来提高程序的可预测性和可测试性。

3.2 Monad: 函数式编程中处理副作用的核心抽象

在函数式编程中，Monad是一种用于处理副作用的核心抽象。它提供了一种结构化的方式来处理计算中的状态、异常、输入输出等副作用，使得程序更加模块化和可组合。

在范畴论中，Monad被定义为一个自函子(endofunctor)加上两个自然变换(有点抽象了)：

• return (也称为unit)：将一个值封装到Monad中。
• bind (也称为flatMap或>>=)：将一个Monad中的值应用到一个函数中，并返回一个新的Monad。

注：要入门范畴论，可以参考《Category Theory for Programmers》这本书。

Monad可以通过以下策略来处理副作用：

• 延迟执行：将副作用操作封装在Monad中，但不立即执行，这样可以将副作用推迟到程序的边缘。
• 显式表示：使副作用成为类型系统的一部分，迫使开发者显式地处理这些效果。
• 组合性：提供了一种方式来组合包含副作用的操作，而不破坏函数的纯粹性。
• 错误处理：提供了一种统一的方式来处理可能失败的操作。
• 状态管理：允许在一系列操作中传递和修改状态，而不需要使用可变变量。

在实际应用中，我们可以根据具体需求选择使用不同的Monad实现。每种Monad都有其适用场景，比如：

• 使用Option(Maybe) Monad处理可能缺失的值，避免空指针异常。
• 使用Result(Either) Monad 处理可能失败的操作，提供更丰富的错误信息。
• 使用IO Monad封装所有的I/O操作，将副作用推迟到程序的边缘。

接下来，我们就结合Go示例来逐一探讨这三种Monad实现。

3.3 Option (Maybe)

Option 用于表示一个值可能存在或不存在，避免了使用null或undefined带来的问题。

// fp-in-go/side-effect/option/main.go

package main

import "fmt"

type Option[T any] struct {
    value   T
    present bool
}

func Some[T any](x T) Option[T] {
    return Option[T]{value: x, present: true}
}

func None[T any]() Option[T] {
    return Option[T]{present: false}
}

func (o Option[T]) Bind(f func(T) Option[T]) Option[T] {
    if !o.present {
        return None[T]()
    }
    return f(o.value)
}

// 使用示例
func safeDivide(a, b int) Option[int] {
    if b == 0 {
        return None[int]()
    }
    return Some(a / b)
}

func main() {
    result := Some(10).Bind(func(x int) Option[int] {
        return safeDivide(x, 2)
    })
    fmt.Println(result) // {5 true}

    result = Some(10).Bind(func(x int) Option[int] {
        return safeDivide(x, 0)
    })
    fmt.Println(result) // {0 false}
}

这段示例程序定义了一个Option结构体：包含一个值和一个表示值是否存在的布尔变量。Some和None函数是Option的创建函数，Some函数：返回一个包含值的Option。None函数返回一个不包含值的Option。Bind方法对Option中的值应用一个函数，如果值不存在则返回None。

3.4 Result (Either)

Result可用于处理可能产生错误的操作，它比Option提供了更多的信息，它可以可以携带错误信息。

// fp-in-go/side-effect/result/main.go

package main

import (
    "fmt"
    "os"
    "strings"
)

type Result[T any] struct {
    value T
    err   error
    isOk  bool
}

func Ok[T any](value T) Result[T] {
    return Result[T]{value: value, isOk: true}
}

func Err[T any](err error) Result[T] {
    return Result[T]{err: err, isOk: false}
}

func (r Result[T]) Bind(f func(T) Result[T]) Result[T] {
    if !r.isOk {
        return Err[T](r.err)
    }
    return f(r.value)
}

// 使用示例
func readFile(filename string) Result[string] {
    content, err := os.ReadFile(filename)
    if err != nil {
        return Err[string](err)
    }
    return Ok(string(content))
}

func processContent(content string) Result[string] {
    // 处理内容...
    return Ok(strings.ToUpper(content))
}

func main() {
    result := readFile("input.txt").Bind(processContent)
    fmt.Println(result) // {HELLO, GOLANG <nil> true}
    result = readFile("input1.txt").Bind(processContent)
    fmt.Println(result) // { 0xc0000a0420 false}
}

这段示例程序定义了一个Result结构体：包含一个值、一个错误信息和一个表示操作是否成功的布尔变量。Ok和Err函数是Result的创建函数，Ok函数返回一个成功的Result。Err函数返回一个失败的Result。Bind方法对成功的Result中的值应用一个函数，如果操作失败则返回错误。

在示例中，我们分别用读取input.txt和不存在的input1.txt来演示成功和错误的两个情况，具体输出结果见上面代码中的注释。

3.5 IO Monad

IO Monad用于封装所有的带有副作用的输入/输出操作，使得这些操作在类型系统中可见，并且可以被推迟执行。

// fp-in-go/side-effect/io-monad/main.go

package main

import (
    "fmt"
    "os"
    "strings"
)

// IO represents an IO operation that, when run, produces a value of type any or an error
type IO struct {
    run func() (any, error)
}

// NewIO creates a new IO monad
func NewIO(f func() (any, error)) IO {
    return IO{run: f}
}

// Bind chains IO operations, allowing for type changes
func (io IO) Bind(f func(any) IO) IO {
    return NewIO(func() (any, error) {
        v, err := io.run()
        if err != nil {
            return nil, err
        }
        return f(v).run()
    })
}

// Map transforms the value inside IO
func (io IO) Map(f func(any) any) IO {
    return io.Bind(func(v any) IO {
        return NewIO(func() (any, error) {
            return f(v), nil
        })
    })
}

// Pure lifts a value into the IO context
func Pure(x any) IO {
    return NewIO(func() (any, error) { return x, nil })
}

// ReadFile is an IO operation that reads a file
func ReadFile(filename string) IO {
    return NewIO(func() (any, error) {
        content, err := os.ReadFile(filename)
        if err != nil {
            return nil, fmt.Errorf("failed to read file: %w", err)
        }
        return string(content), nil
    })
}

// WriteFile is an IO operation that writes to a file
func WriteFile(filename string, content string) IO {
    return NewIO(func() (any, error) {
        err := os.WriteFile(filename, []byte(content), 0644)
        if err != nil {
            return nil, fmt.Errorf("failed to write file: %w", err)
        }
        return true, nil
    })
}

// Print is an IO operation that prints to stdout
func Print(x any) IO {
    return NewIO(func() (any, error) {
        fmt.Println(x)
        return x, nil
    })
}

func main() {
    // Example: Read a file, transform its content, and write it back
    program := ReadFile("input.txt").
        Map(func(v any) any {
            return strings.ToUpper(v.(string))
        }).
        Bind(func(v any) IO {
            return WriteFile("output.txt", v.(string))
        }).
        Bind(func(v any) IO {
            success := v.(bool)
            if success {
                return Pure("File processed successfully")
            }
            return Pure("Failed to process file")
        }).
        Bind(func(v any) IO {
            return Print(v)
        })

    // Run the IO operation
    result, err := program.run()
    if err != nil {
        fmt.Printf("An error occurred: %v\n", err)
    } else {
        fmt.Printf("Program completed: %s\n", result)
    }
}

这个示例提供了一个非泛型版本的IO Monad的Go实现，它允许我们链式组合带有副作用的IO操作，同时保持了一定程度的类型安全（尽管需要类型断言）。在实际使用中，你完全不用自己实现IO Monad，可以直接使用IBM/fp-go中的ioeither，就像本文初那个示例那样。

4. 小结

到这里，关于函数式编程思维的入门介绍就告一段落了！

通过上面的介绍，我们看到函数式编程提供了一种不同于传统命令式编程的思维方式。它强调不可变性、纯函数和函数的组合，为数据流的处理搭建管道，这些特性使得代码更易于理解、测试和并行化。然而，函数式编程也带来了一些挑战，如处理副作用和状态管理的复杂性和难于理解。

学习函数式编程不仅可以扩展我们的编程技能，还能帮助我们以新的方式思考问题和设计解决方案。正如《函数式编程思维》一书中译者所说，接受一种新的编程范式可能需要时间和耐心，但最终会带来新的见解和能力。

在实际应用中，纯粹的函数式编程并不常见，更常见的是将函数式编程的概念和技术与其他编程范式(主要就是命令式范式)相结合。

Go语言虽然不是一个纯函数式语言，但它提供了足够的特性来支持函数式编程风格，如一等公民的函数、闭包和高阶函数等。

最后要记住，编程范式是工具，而不是教条。好的程序员应该能够根据具体问题和场景，灵活地选择和组合不同的编程范式，以创造出最优雅、高效的解决方案。

本文涉及的源码可以在这里下载 – https://github.com/bigwhite/experiments/blob/master/fp-in-go

本文部分源代码由Claude 3.5 sonnet和GPT-4o生成。

5. 参考资料

• 《函数式设计：原则、模式与实践》- https://book.douban.com/subject/36974785/
• 《函数式编程思维》- https://book.douban.com/subject/26587213/
• 《计算机程序的构造和解释》- https://book.douban.com/subject/36787585/
• 《Learning Functional Programming in Go》 – https://book.douban.com/subject/30165168/
• Introduction to fp-go, functional programming for golang – https://www.youtube.com/watch?v=Jif3jL6DRdw
• Investigate Functional Programming Concepts in Go – https://betterprogramming.pub/investigate-functional-programming-concepts-in-go-1dada09bc913
• Investigating the I/O Monad in Go – https://medium.com/better-programming/investigating-the-i-o-monad-in-go-3c0fabbb4b3d

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

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

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

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2024, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2022/07/07/gocn-community-go-book-club-issue2-go-programming-from-beginner-to-master

本文是2022年6月26日我在GoCN社区的Go读书会第二期《Go语言精进之路》直播的文字稿。本文对直播的内容做了重新整理与修订，供喜欢阅读文字的朋友们在收看直播后的揣摩和参考。视频控的童鞋可以关注GoCN公众号和视频号看剪辑后的视频，也可以在B站GopherChina专区下收看视频回放(https://www.bilibili.com/video/BV1p94y1R7jg)。

大家晚上好，我叫白明，是《Go语言精进之路》一书的作者，也是tonybai.com的博主，很荣幸今天参加GoCN社区Go读书会第二期，分享一下我个人在写书和读书方面的经验和体会。

今天的分享包括三方面内容：

• 写书的历程。一些Gopher可能比较好奇，这么厚的一套书是怎么写出来的，今天就和大家聊一聊。
• 《Go语言精进之路》导读。主要是把这本书的整体构思与大家聊聊，希望通过这个导读帮助读者更好地阅读和理解这套书。
• 我个人的读书方法与经验的简要分享。

首先和大家分享一下写书的历程。

一. 写书的历程

1. 程序员的“小目标”与写书三要素

今天收看直播的童鞋都是有追求的技术人员，可能心底都有写一本属于自己的书的小目标。这样可以把自己学习到的知识、技能和经验以比较系统的方式输出给其他人，可以帮助其他人快速学习和掌握本领域的知识、技能和经验。

当然写书还有其他好处，比如：提升名气、更容易混技术圈子、可能给你带来更好的职业发展机会，当然也会给你带来一些额外的副业收入，至于多少，还要看书籍的口碑与销量。

那怎么才能写书呢？作为“过来人”，我总结了三个要素，也是三个条件。

第一个要素是能力。

这个很容易理解。以Go为例，如果你没有在Go语言方面的知识、技能的沉淀，没有对Go语言方方面面的较为深入的理解，你很难写出一本口碑很好的书籍。尤其是那种有原创性、独到见解的著书。而不是对前人资料做系统整理摘抄的编书。编书更常见于教材、字典等。显然著书对作者水平的要求更高。

第二个要素是意愿。

写过书的同学都有体会，写书是一件辛苦活。需要你在正式工作之余付出大量业余时间伏案创作。并且对于小众技术类书籍来说，写书能带来的金钱上的收益和你付出的时长和精力不成正比。就这个问题，我曾与机械工业出版社的营销编辑老师聊过，得到的信息是：Go技术书籍的市场与Java、Python还没法比，即便是像Go语言圣经《Go程序设计语言》的销量也没法与Java、Python的头部书籍销量相比。

第三个要素是机会。

记得小时候十分羡慕那些能出书的人，觉得都是大神级的人物。不过那个时候出书的确很难，机会应该很少，你要不是在学术圈里混很难出书。如今就容易地多了，渠道也多了。每年出版社都有自己的出版计划，各个出版社的编辑老师也在根据计划在各种自媒体上、技术圈子中寻觅匹配的技术作者。

如果你有自己的思路，也可以整理出大纲，并通过某种方式联系到出版社老师，如果匹配就可以出。

另外国外流行电子自助出版，这也给很多技术作者很好的出版机会。比如国内作者老貘写的Go 101系列就是在亚马逊和leanpub上做的自助出版，效果还不错。

以上就是我总结的出书的三个要素，一旦集齐这三个要素呢，出书实际就是自然而然的一件事了。以我为例。

从能力方面来说呢，我大约从2011年开始接触和学习Go语言，算是国内较早的一批Go语言接纳者。Go语言2012年才发布1.0版本，因此那时我接触的Go时还是r60版本，还不是正式的1.0版本。从那时起就一直在跟踪Go演化，日常写一些Go项目的小程序。

Go 1.5实现自举并大幅降低GC延迟，我于是开始在一些生产环境使用Go，并逐渐将知识和经验做了沉淀，在自己的博客上不断做着Go相关内容的输出，反响也不错。

随着输出Go内容的增多，我发现以博客的形式输出，内容组织零散，于是我第一次有了将自己的Go知识系统整理并输出的意愿和想法。

我在实践Go的过程中收到很多Go初学者的提问：Go入门容易，但精进难，怎么才能像Go开发团队那样写出符合Go思维和语言惯例的高质量代码呢？这个问题引发了我的思考。在2017年GopherChina大会我以《go coding in go way》为主题，以演讲的形式尝试回答这个问题，但鉴于演讲的时长有限，很多内容没能展开，效果不甚理想。这进一步增强了我通过书籍的形式系统解答这个问题的意愿。

而当时我家大宝已经长大了，我也希望通过写书这个行动身体力行地给孩子树立一个正面的榜样。中国古语有云：言传身教，我也想践行一下。

机会就这样自然而然的来了！2018年初，机械工业出版社副总编杨福川老师在微信联系到我，和我探讨一下是否可以写一本类似于“Effective Go”的书，当时机械工业出版社华章出版社策划了Effective XXX(编写高质量XXX)系列图书，当时已经出版了C、Python等语言版本的书籍，还差Go语言的。我的出书意愿与出版社的需求甚是匹配，于是我答应的杨老师的要求，成为了这套丛书的Go版本的作者。

2. 写书的过程

我是2018下旬开始真正动笔的。

真正开始码字的时候，我才意识到，写书真不容易，要写出高质量书稿，的确需付出大量时间和汗水。每天晚上、早上都在构思、码字、写代码示例、画插图，睡眠时间很少。记得当时每周末都在奋笔疾书，陪伴家人尤其是孩子的时间很少。

另外我这个人还习惯于把一个知识点讲细讲透，这样每一节的篇幅都不小。因此，写作进展是很缓慢的，就这样，进度一再延期。好在编辑老师比较nice，考虑到书稿质量，没有狠狠催进度。

2020年11月末，我正式向出版社交了初稿，记得初稿有66条，近40w字。

又经过一年的排期、编辑、修订、排版，2021年12月下旬正式出版。

2022年1月《Go语言精进之路》正式上架到各个渠道货架。

到今天为止，出版了近六个月，这本书收获了还不错的口碑，在各个平台上的口碑都在8分以上(注：口碑分数还在动态变化，下图仅为当时的快照，不代表如今的分数)。

能获得大家的认可，让我很是欣慰，觉得写书过程付出的辛苦没有白费。

以上就是我的写书历程。总的来说一句话：写书不易，写高质量的书更难。

接下来我来进行一下《Go语言精进之路》一书的导读。

二. 《Go语言精进之路》导读

也许是“用力过猛”，《Go语言精进之路》一书写的太厚了，无法装订为一册。编辑老师建议装订为两册，即1、2册。很多同学好奇为什么不是上下册而是1、2册，这里是编辑老师的“高瞻远瞩”，目的是为后续可能的“续写”(比如第3册)留足空间，毕竟Go语言还在快速演进，目前的版本还不包含像泛型这样的新语法。不过，目前第3册还尚未列入计划。

本套书共分为10个部分，66个主题。第一册包含了前7个部分，后3部分在第二册中。

1. 整体写作思路

整套书围绕着两个前后关联的思路循序展开。

第一个思路我叫它：精进之路，思维先行。

第二个思路称为：践行哲学，遵循惯例，认清本质，理解原理。

我们先来看看第一个思路。

2. 精进之路，思维先行

收看直播的童鞋都不止学过一门编程语言。大家可能都有过这样的经历：你已经精通A语言，然后在学习B语言的时候用A语言的思维去写B代码，你会觉得写出的B代码很别扭，写出的代码总是感觉不是很地道，总觉得不是那种高质量的B语言代码。

其实，不仅学习编程语言是这样，学自然语言也是一样。最典型的一个例子，大家都学过十几年的英语，但毕业后能用地道的英语表达自己观点的人却不多，为什么呢？那就是我们总用中文的思维方式去组织英语的句子，去说英语，这样再怎么努力也很难上一个层次。

其实，很多语言大师早就意识到了这一点。下面是我收集的这些大师的关于语言与思维的论点，这里和大家分享一下：

“语言决定思维方式” – 萨丕尔假说

“我的语言之局限，即我的世界之局限” – 路德维希·维特根斯坦，语言哲学的奠基人

“不能改变你思维方式的语言，不值得学习” – Alan Perlis（首届ACM图灵奖得主)

我们看到：无论是自然语言界的大师，还是IT界的大佬，他们的观点异曲同工。总之一句话：语言要精进，思维要先行。

3. Part1：进入Go语言编程思维导引

正是因为意识到语言与思维的紧密关系，我在书的第一部分就安排了Go语言编程思维导引，希望大家意识到Go编程思维在语言精进之路上的重要性。

一门编程语言的思维也不是与生俱来的，而是在演进中逐步形成的。所以在这一部分，我安排了Go诞生与演进、Go设计哲学：简单、组合、并发、面向工程。这样做的目的是让大家一起了解Go语言设计者在设计Go语言时的所思所想，让读者站在语言设计者的高度理解Go语言与众不同的设计，认同Go语言的设计理念。因为这些是Go编程语言思维形成的“土壤”。

这一部分最后一节是Go编程思维举例导引，书中给出了C, Haskell和Go程序员在面对同一个问题时，首先考虑到的思维方式以及不同思维下代码设计方式的差异。

知道Go编程思维的重要性后，我们应该怎么做呢？

4. 怎么学习Go编程思维？

学习的本质是一种模仿。要学习Go思维，就要去模仿Go团队、Go社区的优秀项目和代码，看看他们怎么做的。这套书后面的部分讲的就是这个。而“践行哲学，遵循惯例，认清本质，理解原理”就是对后面内容的写作思路的概要性总结。

• 践行哲学

把Go设计哲学用于自己的项目的设计实践中，而不是仅停留在口头知道上。

• 遵循惯例

遵循Go团队的一些语言惯例，比如“comma，ok”、使用复合字面值初始化等，使用这些惯例你可以让你的代码显得很地道，别人一看就懂。

• 认清本质

为了更高效地利用语言机制，我们要认清一些语言机制背后的本质，比如切片、字符串在运行时的表示，这样一来既能帮助开发人员正确使用这些语法元素，同时也能避免入坑。

• 理解原理

Go带有运行时。运行时全程参与Go应用生命周期，因此，只有对Goroutine调度、GC等原理做适当了解，才能更好的发挥Go的威力。

这套书的part2-part10 就是基于对Go团队、Go社区优秀实践与惯例的梳理，用系统化的思路构建出来并循序渐进呈现给大家的。

5. Part2 – 项目基础：布局、代码风格与命名

这部门的内容是每个gopher在开启一个Go项目时都要考虑的事情。

• 项目布局

我见过很多Gopher问项目布局的事情，因为Go官方没有给出标准布局。本书讲解了Go项目的结构布局的演进历程以及Go社区的事实标准，希望能给大家提供足够的参考信息。

• 代码风格

针对Go代码风格，由于代码风格在Go中已经弱化，所以这里主要还是带大家理解gofmt存在的意义和使用方法。

• 命名惯例

关于命名，我不知道大家是否觉得命名难，但对我来说是挺难的，我总是绞尽脑汁在想用啥名(手动允悲)。所以我的原则是“代码未动，命名先行”。 对于Go中变量、标识符等的命名惯例这样的“关键的问题”，我使用了“笨方法”：我统计了Go标准库、Docker库、k8s库的命名情况，并分门别类给出不同语法元素的命名惯例，具体内容大家可以看书了解 。

6. Part3 – 语法基础：声明、类型、语句与控制结构

第三部分讲的很基础，但内容还是要高于基础的。

• 一致的变量声明

我们知道Go提供多种变量声明方式，但是在不同位置该用哪种声明方式可读性好又不容易造坑呢(尤其要注意短变量声明)？书中给出了系统阐述。

• 无类型常量与iota

大家都用过常量，但很多人对于无类型常量与有类型常量区别不了解，书中帮你做了总结。还有，很多人用过iota，但却不理解iota的真正含义以及它能帮你做啥。书中对iota的语义做了说明，对常见用途做了梳理。

• 零值可用

Go提倡零值可用，也内置了有很多零值可用类型，用起来很爽，比如：切片(不全是，仅在append时是零值可用，当用下标访问时，不具备零值可用)、sync包中的Mutex、RDMutex等

其实类比于线程（thread），goroutine也是一种零值可用的“类型”，只是Go没有goroutine这个类型罢了。

如果我们是包的设计者，如果提供零值可用的类型，可以提升包的使用者的体验。

• 复合字面值来初始化

使用复合字面值对相应的变量进行初始化是一个Go语言的惯例， Go虽然提供了new和make，但日常很少用，尤其是new。

• 切片、字符串、map的原理、惯用法与坑

Go是带有runtime的语言，语法层面展示的很多语法元素和runtime层真实的表示并不一致。要想高效利用这些类型，如果不了解runtime层表示还真不行。有时候还有很严重的“坑”。懂了，自然就能绕过坑。

• 包导入

Go源文件的import语句后面跟着的是包名还是包路径？Go编译是不是必须要有依赖项的源码才可以，只有.a是否可以？这些问题书中都有系统说明

• 代码块与作用域

代码块与作用域是Go语言的基础概念，虽然基础，如果理解不好，也是有“坑”的，比如最常见的变量遮蔽等。一旦理解透了，还可以帮你解决意想不到的语法问题和执行语义错误问题。

• 控制语句

Go倡导“一个问题只有一种解决方法”。Go针对每种控制语句仅提供一种语法形式。虽然仅有一种形式，用不好，一样容器掉坑。本套书总结了Go控制语句的惯用法与使用注意事项。

7. Part4 – 语法基础：函数与方法

我们日常编写的Go代码逻辑都在函数或方法中，函数/方法是Go程序逻辑的基本承载单元。

• init函数

init函数是包初始化过程中执行的函数，它有很多特殊用途。并且其初始化顺序对程序执行语义也有影响，这方面要搞清楚。书中对init函数的常见用途做了梳理，比如database/sql包的驱动自注册模式等。

• 成为“一等公民”

在Go中，函数成为了“一等公民”。函数成为一等公民后可以像变量一样，被作为参数传递到函数中、作为返回值从函数中返回、作为右值赋值给其他变量等，书中系统讲解了这个特性都有哪些性质和特殊应用，比如函数式编程等。

• defer语句的惯用法与坑

defer就是帮你简化代码逻辑的，书中总结了defer语句的应用模式。以及使用defer的注意事项，比如函数求值时机、使用开销等。

• 变长参数函数

Go支持变长参数函数。大家可以没有意识到：变长参数函数是我们日常用的最多的一类函数，比如append函数、fmt.Printf系列、log包中提供的按日志严重级别输出日志的函数等。

但变长参数函数可能也是我们自己设计与实现较少的一类函数形式。 变长参数函数能帮我们做什么呢？书中讲解了变长参数函数的常见用途，比如实现功能选项模式等。

• 方法的本质、receiver参数类型选择、方法集合

方法的本质其实是函数，弄清楚方法的本质可以帮助我们解决很多难题，书中以实例方式帮助大家理解这一点。

方法receiver参数类型的选择也是Go初学者的常见困惑，这里书中给出三个原则，参照这三个原则，receiver类型选择就不是问题了。

怎么确定一个类型是否实现接口？我们需要看类型的方法集合。那么确定一个类型方法集合就十分重要，尤其是那些包括类型嵌入的类型的方法集合，书中对这块内容做了系统的讲解。

8. Part5 – 语法核心：接口

• 接口的内部表示

接口是Go语言中的重要语法。Russ Cox曾说过：“如果要从Go语言中挑选出一个特性放入其他语言，我会选择接口”。可见接口的重要性。不过，用好接口类型的前提是理解接口在runtime层的表示，这一节会详细说明空接口与非空接口的内部表示。

• 接口的设计惯例

我们应该设计什么样的接口呢？ 大接口有何弊端？小接口有何优势？多小的接口算是合理的呢？这些在本节都有说明。

• 接口与组合

组合是Go的设计哲学，Go是关于组合的语言。接口在面向组合编程时将发挥重要作用。这里我将提到Go的两种组合方式：垂直组合和水平组合。其中接口类型在水平组合中起到的关键性的作用。书中还讲解了通过接口进行水平组合的几种模式：包裹模式、适配器函数、中间件等。

很多初学者告诉我，他们做了一段时间Go编码了，但还没有自己设计过接口，我建议这样的同学好好读读这一部分。

9. Part6 – 语法核心：并发编程

• 并发设计vs并行设计

学习并发编程首先要搞懂并发与并行的概念，书中用了一个很形象的机场安检的例子，来告诉大家并发与并行的区别。并发关乎结构，并行关注执行

• 并发原语的原理与应用模式

Go实现了csp模型，提供了goroutine、channel、select并发原语。

理解go并发编程。首先要深入理解基于goroutine的并发模型与调度方式。书中对这方面做了深入浅出的讲解，不涉及太多代码，相信大家都能看懂。

书中还对比了go并发模型，一种是csp，一种是传统的基于共享内存方式，并列举了Go并发的常见模式，比如创建、取消、超时、管道模式等。

另外，channel作为goroutine间通信的标准原语，有很多玩法，这里列举了常见的模式和使用注意事项。

• 低级同步原语(sync和atomic)

虽然有了CSP模型的并发原语，极大简化并发编程，但是sync包和原子操作也不能忘记，很多性能敏感的临界区还需要sync包/atomic这样的低级同步原语来同步。

10. Part7 – 错误处理

单独将错误处理拎出来，是因为很多人尤其是来自java的童鞋，习惯了try-catch-finally的结构化错误处理，看到go的错误处理就让其头疼。

Go语言十分重视错误处理，但它也的确有着相对保守的设计和显式处理错误的惯例。

本部分涵盖常见Go错误处理的策略、避免if err != nil写太多的方案，更为重要的是panic与错误处理的差别。我见过太多将panic用作正常处理的同学了。尤其是来自java阵营的童鞋。

11. Part8 – 编程实践：测试、调试与性能剖析

本部分聚焦编码之外的Go工具链工程实践。

• Go测试惯例与组织形式

这部分首先和大家聊聊go test包的组织形式，包括是选择包内测试还是包外测试？何时采用符合go惯例的表驱动的测试用例组织形式？如何管理测试依赖的外部数据文件等。

• 模糊测试(fuzzing test)。

这里的模糊测试并非基于go 1.18的原生fuzzing test进行，写书的时候go 1.18版本尚未发布，而是基于德米特里-维尤科夫的go-fuzz工具。

• 性能基准测试、度量数据与pprof性能剖析

Go原生提供性能基准测试。这一节讲解了如何做性能基准测试、如何编写串行与并行的测试、性能基准测试结果比较工具以及如何排除额外干扰，让结果更准确等方面内容。在讲解pprof性能剖析工具时，我使用一个实例进行剖析讲解，这样理解起来更为直观。

• Go调试

说到Go调试，我们日常使用最多的估计还是print大法。但在print大法之外，其实有一个事实标准的Go调试工具，它就是delve。在这一节中，我讲解了delve的工作原理以及使用delve如何实现并发调试、coredump调试以及在线挂接(attach)进程的调试。

12. Part9 – 标准库、反射与cgo

go是自带电池，开箱即用的语言，拥有高质量的标准库。在国外有些Gopher甚至倡导仅依赖标准库实现go应用。

• 高频使用的标准库包（net、http、strings、time、crypto等)

在这一节，我对高频使用的标准库包的原理和使用进行拆解分析，net、http、标准库io模型、strings、time、crypto等以帮助大家更高效的运用标准库。

• reflect包使用的三大法则

reflect包为go提供了反射能力，书中对反射的实现原理做了讲解，重点是reflect使用的三大法则。

• cgo使用

cgo不是go，但是cgo机制是使用go与c交互的唯一手段。书中对cgo的用法与约束做了详细讲解，尤其是在cgo开启的情况下如何做静态编译值得大家细读。

• unsafe包的安全使用法则

事实证明unsafe包很有用，但要做到安全使用unsafe包，尤其是unsafe.Pointer，需要遵循一定的安全使用法则。书中对此做了举例详细说明。

反射、cgo、unsafe算是高级话题，要透彻理解，需要多阅读几遍书中内容并结合实践。

13. Part10 – 工程实践

• go module

go module在go 1.11版本中引入go，在go 1.16版本中成为go官方默认构建模式。go程序员入门go，精进go都跨不过go module这道坎儿。书中对go module构建模式做了超级系统的讲解：从go构建模式演进历史、go module的概念、原理、惯例、升降级major版本的操作，到使用注意事项等。不过这里还有有一些瑕疵，那就是go module这一节放置的位置太靠后了，应该往往前面提提。如果后面有修订版，可以考虑这么做。

• 自定义go包导入路径

书中还给出了一个自定义go包导入路径的一种实现方案，十分适合组织内部的私有仓库，有兴趣的同学可以重点看看。

• go命令的使用模式详解

这一节将go命令分门别类地进行详细说明。包括：

- 获取与安装的go get/go install
- go包检视的go list
- go包构建的go build
- 运行与诊断的GODEBUG、GOGC等环境变量的功用
- 代码静态检查与重构
- 文档查看
- go代码生成go generate

• Go常见的“坑”

这一节将Go常见的“坑”进行了一次检阅。我这里将坑分为“语法类”和“标准库类”，并借鉴了央视五套天下足球top10节目，对每个坑的“遇坑指数”与“坑害指数”做了点评。

14. 具备完整的示例代码与勘误表

这套书拥有具备完整的示例代码与勘误表，它们都被持续维护，让大家没有读书的后顾之忧。

三. 读书的实践与体会

下面我再分享一下我个人是怎么读书的，包括go技术书籍的读书历程，以及关于读书的一些实践体会。

读书是千人千面的事，没有固定标准的。我的读书方法也不见得适合诸位。大家听听即可，觉得还不错，能借鉴上就最好了。

今天收看直播估计以gopher为主，所以首先说说Go语言书籍的阅读历程

1. Go语言书籍阅读历程：先外后内

对于IT技术类图书，初期还是要看原版的。这个没办法，因为it编程技术绝大多数来自国外。

我读的第一本Go技术书就是《the way to go》，至今这本书也没有引入国内。这是一本Go语言百科全书，大多数内容如今仍适用。唯一不足是该书成书于Go 1.0发布之前，使用的好像是r60版本，有少部分内容已经不适用。

后来Go 1.0发布后，我还陆续读过Addison-Wesley出版的《programming in go》和《The Go Programming Language Phrasebook》，两本书都还不错。

2015年末的布莱恩.克尼根和go核心团队的多诺万联合编写的《The Go Programming Language》，国内称之为Go圣经的书出版了，这让外文go技术书籍达到了巅峰，后来虽然也有go书籍书籍陆续出版，但都无法触及go圣经的地位。

说完外文图书，我再来说说中文Go图书的阅读历程。

我读过的第一本中文Go书籍是2012年许式伟老师的《Go语言编程》，很佩服许老师的眼光和魄力，七牛云很早就在生产用go。

第二本中文Go书籍是雨痕老师的《go学习笔记》，这也是国内第一本深入到go底层原理的书籍(后半部分)，遗憾的是书籍停留在go 1.5(还是go 1.6)的实现上，没有随Go版本演进而持续更新。

柴大和曹大合著的《go高级编程》也是一本不错的go技术书籍，如果你要深入学习cgo和go汇编，建议阅读此书。

后面的《Go语言底层原理剖析》和《Go语言设计与实现》也都是以深入了解Go运行机制为目标的书籍，口碑都很好，对这方面内容感兴趣的gopher，可以任意挑一本学习。

2. 自己的读书方法

我的读书方法其实不复杂，主要分为精读和泛读。

• 阅读方式：好书精读，闲书泛读

好书，集中一大段时间内进行阅读。 闲书(不烧脑)，通常是 碎片化阅读。

• 精读方法：摘录+脑图+行动清单

摘录就是将书中的观点和细节摘录出来，放到读书笔记，最好能用自己的语言重新描述出来，这样印象深刻，理解更为透彻。

脑图，概括书的思维脉络，防止读完就忘记。 通过脑图，我至少看着脉络能想起来。

行动清单：如果没有能输出行动清单，那这本书对你来说意义就不大。 什么是好书，好书就是那种看完后很迫切的想基于书中的观点做点什么。行动清单将有助于我在后续的行动中反复理解书中内容，提高知识的消化率和理解深度。

• 泛读方法：碎片化+听书

泛读主要是碎片化快读或听书，主要是坐地铁，坐公交，散步时。开车时在保证安全的前提下，可以用听书的方式。

四. 小结

本次分享了三块内容，这里小结一下：

• 写书历程和写书三要素：能力 + 意愿 + 机会；
• Go精进之路导读：思维先行，践行哲学，遵循惯例，认清本质，理解原理；
• 读书方法：选高质量图书精读(脑图+细节摘录+行动清单）。

五. Q&A

• 在实际开发中有没有什么优雅的处理error的方法？

建议看《Go语言精进之路》第一册第七部分中关于error处理的内容。

• 是否在工作中使用过六边形架构以及依赖注入的处理经验?

暂没有使用过六边形架构，生产中没有使用过Go第三方依赖注入的方案。

• 后面会有泛型和模糊测试的补充么？

从书籍内容覆盖全面性的角度而言，我个人有补充上述内容的想法，但还要看现在这套书的销售情况以及出版社的计划。目前还没列入个人工作计划。

• 作者总结一系列go方法论、惯例等很实用，这种有逻辑的思考和见解是怎么形成的？

没有特意考虑过是怎么形成的。个人平时喜欢多问自己几个为什么，形成让自己信服的工作和学习逻辑。(文字稿补充：同理心、多总结、多复盘、多输出)。

学习Go惯例、方法论，可以多多看Go语言开源项目自身的代码评审，看看Go contributor写代码的思路和如何评审其他贡献者的代码的。(文字稿补充：在这一过程中，潜移默化的感受Go编程思维)。

• 如何阅读大型go项目的源码？

我个人的方法就是自上而下。先拆分结构，然后找入口。如果是一个可执行的go程序，还是从入口层层的向后看。然后通过一些工具，比如我个人之前开发的函数调用跟踪工具，查看程序执行过程中的函数调用次序。

更细节的内容，还是要深入到代码中去查看。

• 对Go项目中的一些设计模式的看法？如何使用设计模式，使用时注意哪些事项？

设计模式在go语言中并不是一个经常拿出来提的东西。我之前的一个观点：在其他语言中，需要大家通过一些额外细心的设计构建出来的设计模式，在Go语言中是自然而然就有的东西。

我在自己的日常编码过程中，不会太多从如何应用设计模式的角度思考，而是按照go设计哲学，去考虑并发设计、组合的设计，而不是非要套用那23个经典设计模式。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与Go应用领域的知识、技巧与实践，并增加诸多互动形式。欢迎大家加入！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

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

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2022, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2022/04/23/taking-a-closer-look-at-programming-thinking-in-go

经过十几年的演化和发展，Go语言在全世界范围内已经拥有了百万级别的拥趸，在这些开发者当中，除了一部分新入行的编程语言初学者之外，更多的是从其他编程语言阵营转过来的开发者。由于Go语言上手容易，在转Go的初期大家很快就掌握了Go的语法。

但在编写更多Go代码之后，很多人发现自己写的Go代码总是感觉很别扭，并且总是尝试在Go语言中寻找自己上一门语言中熟悉的语法元素。自己的Go代码风格似乎和Go标准库、主流Go开源项目的代码在思考角度和使用方式上存在不小差异，并且每每看到Go核心开发团队的代码时总有一种醍醐灌顶的感觉。出现这种情况的主要原因就是大脑中上一门编程语言的思维方式在“作祟”。

本文将通过《Go语言精进之路：从新手到高手的编程思想、方法与技巧》这本书的内容来详细看一看编程语言与编程思维的关系以及Go语言的编程思维究竟是什么，以帮助大家更加深入地理解Go编程。

了解Go编程思维之前，我们先看看思维与语言之间究竟有什么联系呢？

1.语言与思维——来自大师的观点

在人类自然语言学界有一个很著名的假说——“萨丕尔—沃夫假说”，这个假说的内容是这样的：“语言影响或决定人类的思维方式。”

说到这个假说，我们不能不提及在2017年年初国内上映了一部口碑不错的美国科幻大片《降临》，这部片子改编自雨果奖获得者华裔科幻小说家Ted姜的《你一生的故事》。片中主线剧情的理论基础就是“萨丕尔—沃夫假说”。更夸张的是片中直接将该假说应用到外星人语言上，将其扩展到宇宙范畴。片中的女主作为人类代表与外星人沟通，并学会了外星语言，从此思维大变，拥有了预知未来的“超能力”，这也算是语言影响思维的极致表现了。

奇妙的是，在编程语言界，有位大师级人物也有着与“萨丕尔-沃夫假说”异曲同工的观点和认知，他就是首届图灵奖得主、著名计算机科学家艾伦·佩利（Alan J. Perlis），他从另外一个角度提出：“不能影响到你的编程思维方式的编程语言不值得去学习和使用。”

2.现实中的“投影”

从上述大师们的理论和观点，我们看到了语言与思维之间存在着某种联系。那么两者间的这种联系在真实编程世界中的投影又是什么样子的呢？我们来看一个简单的编程问题——素数筛：

• 问题描述：素数是一个自然数，它具有两个截然不同的自然数除数：1和它本身。这里的问题是如何找到小于或等于给定整数n的素数。针对这个问题，我们可以采用埃拉托斯特尼素数筛算法。

• 算法描述：先用最小的素数2去筛，把2的倍数剔除掉；下一个未筛除的数就是素数（这里是3）。再用这个素数3去筛，筛除掉3的倍数… 这样不断重复下去，直到筛完为止（算法图示见图1）。

下面是该素数筛算法的不同编程语言的实现版本。

（1）C语言版本

// sieve.c
#include <stdio.h>

#define LIMIT  50
#define PRIMES 10

void sieve() {
    int c, i,j,numbers[LIMIT], primes[PRIMES];

    for (i=0;i<LIMIT;i++){
        numbers[i]=i+2; /*fill the array with natural numbers*/
    }

    for (i=0;i<LIMIT;i++){
        if (numbers[i]!=-1){
            for (j=2*numbers[i]-2;j<LIMIT;j+=numbers[i])
                numbers[j]=-1; /* 筛除非素数 */
        }
    }

    c = j = 0;
    for (i=0;i<LIMIT&&j<PRIMES;i++) {
        if (numbers[i]!=-1) {
            primes[j++] = numbers[i]; /*transfer the primes to their own array*/
            c++;
        }
    }

    for (i=0;i<c;i++) printf("%d\n",primes[i]);
}

（2）Haskell版本

// sieve.hs

sieve [] = []
sieve (x:xs) = x : sieve (filter (\a -> not $ a `mod` x == 0) xs)
n = 100
main = print $ sieve [2..n]

（3）Go语言版本

// sieve.go

func Generate(ch chan<- int) {
    for i := 2; ; i++ {
        ch <- i
    }
}

func Filter(in <-chan int, out chan<- int, prime int) {
    for {
        i := <-in
        if i%prime != 0 {
            out <- i
        }
    }
}

func main() {
    ch := make(chan int)
    go Generate(ch)
    for i := 0; i < 10; i++ {
        prime := <-ch
        print(prime, "\n")
        ch1 := make(chan int)
        go Filter(ch, ch1, prime)
        ch = ch1
    }
}

对比上述的三个语言版本的素数筛算法的实现，我们看到：

• C版本的素数筛程序是一个常规实现。它定义了两个数组：numbers和primes，“筛”的过程在numbers这个数组中进行（即基于纯内存修改），非素数的数组元素被设置为-1，便于后续提取；

• Haskell版本采用了函数递归的思路，通过“filter操作集合”，用下面谓词（过滤条件）筛除素数的倍数，将未筛除的数的集合作为参数传递归递给下去；

\a -> not $ a `mod` x == 0；

• Go版本程序实现了一个并发素数筛，它采用的是goroutine的并发组合。程序从素数2开始，依次为每个素数建立一个goroutine，用于作为筛除该素数的倍数。ch指向当前最新输出素数所位于的筛子goroutine的源channel，这段代码来自于Rob Pike的一次关于并发的分享。Go版本程序的执行过程可以用图2立体的展现出来。

3.Go语言原生编程思维

通过上述这个现实中的问题我们可以看到：面对同一个问题，来自不同编程语言的程序员给出了思维方式截然不同的解决方法：C的命令式思维、Haskell的函数式思维和Go的并发思维。结合“萨丕尔—沃夫假说”，我们可以得到一个未经理论证实但又确实对现实有影响的推论：编程语言影响编程思维，或者说每种编程语言都有属于自己的原生编程思维。

Go语言诞生较晚，大多数Gopher（包括笔者在内）第一语言都不是Go，都是“半路出家”从其他语言转过来的，如C、C++、Java、Python等。每种语言都有自己的原生编程思维。比如：C语言相信程序员，提供了指针和指针运算，让C程序员天马行空的发挥，接近底层的直接内存操作让C程序拥有很高的性能；C++支持多范式（命令式、OO和泛型），虽不强迫程序员使用某个特定的范式，但推荐使用最新代表现代语言发展特色的泛型等高级范式；Python语言更是形成了Pythonic规则来指导Python程序员写出符合Python思维或惯用法的代码。

经验告诉我们但凡属于某个编程语言的高质量范畴的代码，其必定是在这种编程语言原生思维下编写的代码。如果用A语言的思维去编写B语言的代码（比如用OO思维写C代码，用命令式的思维写Haskell代码等），那么你写出的代码多半无法被B语言社区所认可，更难以成为高质量代码的典范。并且，如果沿着这样的方向去学习和实践B语言，那么结果只能是“南辕北辙”，离编写出高质量代码的目标渐行渐远。

那Go原生编程思维究竟是什么呢？一门编程语言的编程思维是由语言设计者、语言实现团队、语言社区、语言使用者在长期的演化和实践中形成的一种统一的思维习惯、行为方式、代码惯用法和风格。Go语言从诞生到现在也近十年多了。经过Go设计哲学熏陶、Go开发团队的引导和教育、Go社区的实践，Go语言也渐渐形成了属于自己的原生编程思维，或者说形成了符合Go语言哲学的Go语言惯用法（idiomatic go）。它们是Go语言的精华，也是构建本书内容的骨架，并值得我们用一本书的规模去详细呈现。因此可以说阅读本书的过程也是学习和建立Go语言原生编程思维的过程。

4. 小结

本文详细介绍了编程语言与编程思维之间的联系。我们学习和使用一门编程语言，目标就是要用这门语言的原生思维方式去编写高质量代码。学习Go，就要用Go的原生编程思维去写Go代码，而不是用其他语言的思维方式。掌握Go原生编程思维就是我们通往高质量Go编程的学习方向和必经之路。如果您想要了解更多有关Go编程思维的内容，推荐您详细阅读我的新作《Go语言精进之路：从新手到高手的编程思想、方法与技巧》。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite
• “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2022, bigwhite. 版权所有.

注：本文是首发于笔者微信公众号“iamtonybai”上的付费文章，这里免费分享给大家！

在2020.11.9~11.13举行的全球最具影响力的Go语言技术大会GopherCon 2020上，Go语言之父之一的Robert Griesemer为全世界Gopher们带来了本次大会最重量级的演讲“Typing [Generic] Go”。

在这个演讲中，Robert Griesemer向Gopher们介绍了自从今年中旬在Go官网发表文章“The Next Step for Generics”以来Go泛型(Go Generics)技术草案的最新变化，并详细介绍了类型参数(type parameter)是如何满足Go现有的类型系统的，以及Go编译器是如何对Go泛型代码进行类型检查的。

本文整理了此次演讲的重点内容，供广大Gopher参考，希望能为大家理解Go泛型带来帮助。

一. 预备知识

为了更好地理解Robert Griesemer的讲解，这里先带着大家回顾一下Go generics技术草案演化史。

• 2017年7月，Go核心团队领军人物Russ Cox在Gophercon 2017大会上发表演讲“Toward Go 2”，正式吹响Go向下一个阶段演化的号角；
• 2018年8月，在Gophercon 2018大会结束后不久，Go核心团队发布了Go2 draft proposal，这里面涵盖了由Ian Lance Taylor和Robert Griesemer操刀主写的Go泛型的第一版draft proposal。这版草案引入了contract关键字来定义泛型类型参数(type parameter)的约束、类型参数放在普通函数参数列表前面的小括号中，并用type关键字声明：

// 第一版泛型技术草案中的典型泛型语法

contract stringer(x T) {
    var s string = x.String()
}

func Stringify(type T stringer)(s []T) (ret []string) {

}

• 2019年7月，Ian Lance Taylor在GopherCon 2019大会上发表演讲“Why Generics?”，并更新了泛型的技术草案，简化了contract的语法设计：

// 简化后的contract语法如下：

contract stringer(T) {
    T String() string
}

• 2020年6月，《Featherweight Go》论文发表在arxiv.org上，该论文缘于Rob Pike向著名计算机科学家、函数语言专家、Haskell语言的设计者之一、Java泛型的设计者PHILIP WADLER发出的一次邀请，希望PHILIP WADLER帮助Go核心团队解决Go语言的泛型扩展问题：

而这篇论文则是对这次邀请的回应。这篇论文为Go语言的一个最小语法子集设计了泛型语法Featherweight Generic Go(FGG)，并成功地给出了FGG到Feighterweight Go(FG)的可行性实现的形式化证明。

该篇论文采用monomorphisation(单态)的实现，而非Java使用的擦触法(Erasure)，这样的好处之一是如果代码中没有使用任何泛型抽象，程序的运行时不会因支持泛型而承担额外的消耗。

该论文的形式化证明给Go团队带来了信心，也是的Go团队在一些语法问题上达成更广泛的一致。

• 2020.6月末，Ian Lance Taylor和Robert Griesemer在Go官方博客发表了文章《The Next Step for Generics》，介绍了Go泛型工作的最新进展。Go团队放弃了之前的技术草案，并重新编写了一个新草案。在这份新技术方案中，Go团队放弃了引入contract关键字作为泛型类型参数的约束，而采用扩展后的interface来替代contract。这样上面的Stringify函数就可以写成如下形式：

type Stringer interface {
    String() string
}

func Stringify(type T Stringer)(s []T) (ret []string) {
    ... ...
}

同时，Go团队还推出了可以在线试验Go泛型语法的playground：https://go2goplay.golang.org，这样gopher们可以直观体验新语法，并给出自己的意见反馈。

• 2020年11月的GopherCon 2020大会，Griesemer与全世界Gopher同步了Go泛型的最新进展和roadmap，在最新的技术草案版本中，小括号被方括号取代，类型参数前面的type关键字也不再需要了：

func Stringify[T Stringer](s []T) (ret []string) {
    ... ...
}

go2goplay.golang.org也支持了方括号语法，gopher可以在线体验。

下面我们就来看看Griesemer对最新Go泛型技术草案的详细讲解。

二. 类型参数(Type parameters)技术草案详解

这版草案与2019年中旬发布的草案的最大变动就是使用interface而不是contract来表达对类型参数的约束。

该版设计的主要特性：

• 类型参数(Type parameters) – 一种将类型或函数进行参数化的机制
• 约束(Constraints) – 一种表达对类型参数的约束的机制
• 类型推导(Type inference，可选)

普通函数参数列表 vs. 泛型函数的类型参数列表

我们知道，普通函数的参数列表是这样的：

(x, y aType, z anotherType)

• x, y, z是形参(parameter)的名字，即变量；
• aType，anotherType是形参的类型，即类型。

我们再来看一下类型参数(type parameter)列表：

[P, Q aConstraint, R anotherConstraint]

• P，Q，R是类型形参的名字，即类型；
• aConstraint，anotherConstraint代表类型参数的约束(constraint)，可以理解为一种元类型(meta-type，即修饰类型的类型)。

注：按惯例，类型参数(type parameter)的名字都是头母大写的。

为什么需要类型参数(type parameter)

我们先来看一下当前Go语言标准库中提供的排序方案：

// $GOROOT/src/sort/sort.go
type Interface interface {
        Len() int
        Less(i, j int) bool
        Swap(i, j int)
}

func Sort(data Interface) {
    ... ...
}

为了应用这个排序函数Sort，我们需要让被排序的类型实现sort.Interface接口，就像下面例子中这样：

type IntSlice []int

func (p IntSlice) Len() int           { return len(p) }
func (p IntSlice) Less(i, j int) bool { return p[i] < p[j] }
func (p IntSlice) Swap(i, j int)      { p[i], p[j] = p[j], p[i] }

func main() {
        sl := IntSlice([]int{89, 14, 8, 9, 17, 56, 95, 3})
        fmt.Println(sl)
        sort.Sort(sl)
        fmt.Println(sl)
}

这真是我们想要的实现方式吗？我们真正需要的是这样的：

func Sort(list []Elem)

// 使用
var myList = []Elem{...}
Sort(myList)

解决办法：使用type parameter(类型参数或叫做参数化的类型，将类型作为参数传递)：

约束(constraints)

约束(constraint)规定了一个类型实参(type argument)必须满足的条件要求。而在泛型Go中，我们使用interface来定义约束。

如果某个类型实现了某个约束(规定的所有条件要求)，那么它就是一个合法的类型实参。

下面是一个泛型版本的Sort函数：

func Sort[Elem interface{ Less(y Elem) bool }](list []Elem)

我们看到上面函数Sort的类型形参(type parameter)Elem的约束是一个interface，这样传入的类型实参(type argument)只要实现了该接口即可。

约束的定义中也可以引用类型形参，比如下面这个泛型函数：

类型形参的声明与作用域

类型参数的作用域始于[，终于泛型函数的函数体结尾或泛型类型的声明结尾。

泛型的类型具化与类型检查

下面是一个使用泛型版本Sort函数的例子：

func Sort[Elem interface{ Less(y Elem) bool }](list []Elem)

type book struct{…}
func (x book) Less(y book) bool {…}
var bookshelf []book
…
Sort[book](bookshelf) // 泛型函数调用

上面的泛型函数调用Sort[book](bookshelf)将分成两个阶段：

1. 具化(instantiation)

形象点说，具化(instantiation)就好比一家生产“排序机器”的工厂根据要排序的对象的类型将这样的机器生产出来的过程。以上面的例子来说，整个具化过程如下：

• 工厂接单：Sort[book]，发现要排序的对象类型为book；
• 模具检查与匹配：检查book类型是否满足模具的约束要求(即是否实现了Less方法)，如满足，则将其作为类型实参替换Sort函数中的类型形参，结果为Sort[book interface{ Less(y book) bool }]；
• 生产机器：将泛型函数Sort具化为一个新函数，这里将其起名为booksort，其函数原型为func([]book)。本质上booksort := Sort[book]。

1. 调用(invocation)

一旦“排序机器”被生产出来，那么它就可以对目标对象进行排序了，这和普通的函数调用没有区别。这里就相当于调用booksort(bookshelf)，整个过程只需检查传入的函数实参(bookshelf)的类型与booksort函数原型中的形参类型([]book)是否匹配即可。

用伪代码来表述上面两个过程如下：

Sort[book](bookshelf)

<=>

具化：booksort := Sort[book]
调用：booksort(bookshelf)

泛型类型

除了函数可以携带类型参数变身为“泛型函数”外，类型也可以拥有类型参数而化身为“泛型类型”：

type Lesser[T any] interface{
   Less(y T) bool
}

上面代码中的any代表没有任何约束，等价于interface{}。

泛型类型的类型参数的声明与作用域范围

泛型类型的类型参数的声明方式如下，类型参数的作用域范围也同见下图：

用泛型类型改造Sort

用泛型类型定义一个具名的约束条件- Lesser接口类型：

type Lesser[T any] interface{
   Less(y T) bool
}

使用Lesser[T]作为约束的Sort函数可以这样写：

func Sort[Elem Lesser[Elem]](list []Elem)

注意：任何泛型函数或泛型类型在使用前都必须先“具化(instantiation)”。

我们再来看看Sort函数的内部实现：

func Sort[Elem Lesser[Elem]](list []Elem) {
    ...
    var i, j int
    ...
    if list[i].Less(List[j]) {
        ...
    }
    ...
}

• 这里的list[i]和list[j]的类型是Elem；
• Elem不是一个接口类型，它是泛型函数(Sort)的类型参数，Lesser[Elem]是作为类型参数的约束而存在的，不要与函数常规参数列表混淆。

再次强调：类型参数是一个真实的类型，不是一个接口类型(变量)，当然我们可以使用一个接口类型作为类型实参来具化一个泛型函数或泛型类型。

实参类型自动推导(Argument type inference)

我们是想要：

Sort[book](bookshelf)

还是：

Sort(bookshelf)

显然是后者。我们希望Go编译器能够根据传入的变量自动推导出类型参数的实参类型。

这样，在具化之前，如果泛型函数调用没有显式提供实参类型，那么Go编译器将进行自动实参类型推导。有了是实参类型的自动推导，大多数泛型调用的方式与常规函数调用一致。

类型列表(type lists)

到这里，约束仅限于描述方法要求。下面的函数调用仍然无法工作：

Sort([]int{1, 2, 3})

因为原生的int类型不满足Elem的约束，没有实现Less方法。虽然我们可以用下面替代方法实现整型切片的排序：

type myInt int
func (x myInt) Less(y myInt) bool { return x < y }

但这还是太麻烦了。

Go泛型扩展了interface语法，除了让interface拥有自己的方法列表外，还支持在interface中定义类型列表(type list)：

type Float interface {
   type float32, float64
}

// float32和float64都可以作为类型实参传递给Sin
func Sin[T Float](x T) T

现在，一个类型实参要想满足约束，要么它实现了约束中的所有方法，要么它或它的底层类型(underlying type)在约束的类型列表中。

下面是一个泛型函数min的声明与约束定义：

func min[T Ordered](x, y T) T ...

type Ordered interface {
    type int, int8, int16, ..., uint, uint8, uint16, ..., float32, float64, string
}

函数min的实现如下：

func min[T Ordered](x, y T) T {
    if x < y {
        return x
    }
    return y
}

• x和y的类型都是T，T类型要满足约束Ordered；
• x < y是合法的，因为在Ordered的类型列表中的每个类型都支持"<"比较。

但不同类型参数代表的却是不同类型：

func invalid[Tx, Ty Ordered](x Tx, y Ty) Tx {
    ...
    if x < y { // 不合法
        ...
    }
}

• x的类型是Tx，y的类型是Ty；
• Tx和Ty是不同类型；
• "<"需要两个操作数拥有相同的类型。

类型列表应用的典型示例

• 将[]byte和string的操作整合在一起

我们知道目前标准库中有一个bytes包和一个strings包，这两个包一个用于处理[]byte，一个则用于处理string。但使用过这两个包的gopher会发现，这两个包中大部分函数和方法是一样的，甚至处理逻辑都是一样的。有了泛型后，我们可以将对两种类型的大部分操作整合在一起，以Index函数为例：

type Bytes interface {
   type []byte, string
}

// Index returns the index of the first instance of sep
// in s, or -1 if sep is not present in s.
func Index[bytes Bytes](s, sep bytes) int

• 类型参数(type parameter)之间的关系

type Pointer[T any] interface {
    type *T
}

func f[T any, PT Pointer[T]](x T)

或

func foo[T any, PT interface{type *T}](x T)

上面是基于类型列表表述“一个类型的指针类型”约束的方案。PT的实参的类型必须是T的实参类型的指针类型。

下面这几个函数和接口很大可能会加入到标准库：

func BasicSort[Elem Ordered](list []Elem)

func Sort[Elem Lesser[Elem]](list []Elem)

type Lesser[Elem any] interface {
    Less(Elem) Elem
}

小结

关于泛型声明：

• 类型参数列表和普通参数列表相似，只是使用"[ ]"括起；
• 函数和类型都可以拥有类型参数列表；
• 使用interface表达对类型参数的约束。

关于泛型使用：

• 泛型函数和类型在使用之前必须先“具化(instantiated)”；
• 类型自动推导可实现函数隐式具化；
• 如果类型实参满足约束，那么具化才会合法。

截至2020.10月份的泛型设计草案版本，我们对以下特性设计的满意度为：

三. 结束语

“能力越大，责任越大”

• 类型参数(泛型)是Go工具集中的新成员；
• 它与语言的其他部分正交；
• 其正交性也打开了编码风格的一个新维度。

泛型引入了抽象，无用的抽象带来复杂性。请三思而后行！

示例1

func ReadAll(r io.Reader) ([]byte, error)

对比：

func ReadAll[reader io.Reader](r reader) ([]byte, error)

=> 引入泛型的版本并未解决任何实际问题(还带来了复杂难以理解的抽象)

示例2

// Drain drains any elements remaining on the channel.
func Drain[T any](c <-chan T)

// Merge merges two channels of some element type into
// a single channel.
func Merge[T any](c1, c2 <-chan T) <-chan T

=> 类型参数让以往无法实现的逻辑成为现实。

何时使用泛型

• 增强静态类型安全性
• 更高效的内存使用
• (显著的)更好的性能

泛型是带有类型检查的宏(macro)。使用宏之前请三思！

接下来的工作

Go核心团队正在着手做出一个完整的泛型实现，以便我们解决所有未解决的问题。我们继续欢迎大家的反馈！

如何抢先体验泛型：

• playground: https://go2goplay.golang.org/
• go2go命令工具：git checkout dev.go2go

注：2020.11.21日，Go开发团队技术负责人Russ Cox在golang-dev上的mail确认了Go泛型(type parameter)将在Go 1.18版本落地，即2022.2月份。

关注公众号“iamtonybai”，fgg获取论文“Featherweight Go”下载链接；发送gophercon2020获取GopherCon 2020大会技术ppt资料。

“Gopher部落”知识星球开球了！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！星球首开，福利自然是少不了的！2020年年底之前，8.8折(很吉利吧^_^)加入星球，下方图片扫起来吧！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订阅！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

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

Gopher Daily(Gopher每日新闻)归档仓库 - https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2021, bigwhite. 版权所有.

同时该专访稿首发于开源中国开源访谈栏目，大家可以点击这里看到首发原稿。

1、首先请介绍一下自己

大家好！我叫白明（Tony Bai），目前是东软云科技的一名架构师，专职于服务端开发，日常工作主要使用Go语言。我算是国内较早接触Go语言的程序员兼Advocater了，平时在我的博客、微博和微信公众号”iamtonybai”上经常发表一些关于Go语言的文章和Go生态圈内的信息。

在接触Go之前，我主要使用C语言开发电信领域的一些后端服务系统，拥有多年的电信领域产品研发和技术管理经验。我个人比较喜换钻研和分享技术，是《七周七语言》一书的译者之一，并且坚持写技术博客十余年。同时我也算是一个开源爱好者，也在github上分享过自己开发的几个小工具。

目前的主要研究和关注的领域包括：Go、Kubernetes、Docker、区块链和儿童编程教育等。

2、最初是因为什么接触和使用 Go 语言的？它哪方面的特性吸引了您？

个人赶脚：选编程语言和谈恋爱有些像（虽然我只谈过一次^_^），我个人倾向一见钟情。我个人用的最多的编程语言是Go、C，这两门语言算是我在不同时期的“一见钟情”的对象吧，也是最终“领（使）证（用）”的，前提：编程世界是“一夫多妻制”^0^。

当然早期也深入过C++，后来Java、Ruby、Common Lisp、Haskell、Python均有涉猎，这些语言算是恋爱对象，但最终都分手了。

最初接触到Go应该是2011年，那是因为看了Rob Pike的3 Day Go Course，那时Go 1.0版本还没有发布，如果没记错，Rob Pike slide中用的还是Go r60版本的语法。现在大脑中留存的当时的第一感觉就是“一见钟情”！

现在回想起来，大致有这么几点原因：

• Go与C一脉相承，对于出身C程序员的我来说，这一语言传承非常自然，多体现在语法上；
• Go语言非常简单，尤其是GC、并发goroutine、interface，让我眼前一亮；
• Rob Pike的Go Course Slide组织的非常好，看完三篇Slide，基本就入门了。

于是在那之后，又系统阅读了Ivo Balbaert的《The Way To Go》、《Programming in Go – Creating Applications for the 21st Century》等基本新鲜出炉的书，于是就走入了Go语言世界。

不过当时Go1尚未发布，Go自身也有较大变化，工作中也无法引入这门语言，2013年对Go的关注有些中断，2014年又恢复，直至今天。现在感觉到：如果工作语言与兴趣语言能保持一致是多么幸福的一件事啊。

3、有人说 Go 是互联网时代的 C 语言，对于这两门语言，您是怎么看的？

如果没记错，至少在国内，第一个提出这种观点的是现七牛的ceo许式伟了，老许是国内第一的Go 鼓吹者，名副其实；而且许式伟的鼓吹不仅停留在嘴上，更是付诸于实践：据说其七牛云的基础设施基本都是Go开发的。因此，对他的“远见卓识”还是钦佩之至的。

C语言缔造的软件行业的成就是举世瞩目，也是公认的。其作者Dennis Ritchie被授予图灵奖就是对C语言最大的肯定和褒奖。C语言缔造了单机操作系统和基础软件的时代：Unix、Linux、nginx/apache以及无数以*inx世界为中心的工具，是云时代之前最伟大的系统编程语言和基础设施语言。

至于 “Go是互联网时代的 C 语言”这一观点，如果在几年前很多人还会疑惑甚至不懈，但现在来看：事实胜于雄辩。我们来看看当前CNCF基金会(Cloud Native Computing Foundation)管理的项目中，有一大半都是Go语言开发的，包括Kubernetes、Prometheus等炙手可热的项目；这还不包括近两年最火的docker项目。事实证明：Go已成为互联网时代、云时代基础设施领域、云服务领域的最具竞争力的编程语言之一。

不过和C不同的是，Go语言还在发展，还在演进，还有巨大的提升空间，Gopher群体还在变大，去年再次成为Tiboe的年度语言就是例证。

当然我们还得辩证的看，Go语言虽然在云时代基础设施领域逐渐继承C语言的衣钵，但是由于语言设计理念和设计哲学上的原因，在操作系统以及嵌入式领域，Go还在努力提升。

4、Go 也经常被拿来和 Java、Rust 等语言比较，您认为它最适合的使用场景有哪些？

早期对Java有所涉猎，但止步于Java体量过重和框架过多；Rust和Go一样是近几年才兴起的一门很有理想、很有抱负的编程语言，其目标就是安全的系统级编程语言，运行性能极佳，用以替代C/C++的，但就像前面所提到的那样，第一眼看到Rust的语法，就没有那种“一见钟情”的赶脚，希望Rust不要像C++那样，演变的那么复杂。

Go从其第一封设计email出炉到如今已有十年了，我觉得也不应该由我来告诉大家Go更适合应用在什么领域了，事实摆在那里：“大家都用的地方，总是对的”。这里我只是大致归纳一下：

• 云计算基础设施领域

  代表项目：docker、kubernetes、etcd、consul、cloudflare CDN、七牛云存储等。

• 基础软件

  代表项目：tidb、influxdb、cockroachdb等。

• 微服务

  代表项目：go-kit、micro、monzo bank的typhon、bilibili等。

• 互联网基础设施

  代表项目：以太坊、hyperledger等。

Go在数据科学、人工智能领域也有较大进展，希望在将来能看到Go在这些领域有杀手级项目出现。

5、Go发展已有10 年，其特性随着版本的迭代不断在更新，您觉得它最好的和最需要改进的特性分别有哪些？

每种语言都有自己的设计哲学和设计者的考量。我在GopherChina 2017的topic中就提到过Go语言的价值观，其中之一就是Simplicity，即简单。相信简单也是让很多开发者走进Gopher世界的重要原因。从今年GopherCon 2017大会上Russ Cox的“Toward Go 2”的主题演讲中，我们也可以看出：Go team并不会单纯地为了迎合community的意愿去堆砌feature，那go势必走上c++的老路，变得日益复杂，Go受欢迎的基础之一就不存在了。

但演进就一定会要付出代价的，尤其是Go1的约束在前。从我个人对Go的应用来看，最想看到的是包管理和error处理方面的体验提升。但我觉得这两点都是可以通过渐进改进实现的，甚至不会影响到Go1兼容性，不会像引入generics机制，实现难度也不会太高。

对于目前的error handling机制，我个人并没有太多的排斥，这可能是因为我出身C程序员的缘故吧。在error handling这块，只是希望能让gopher拥有更好的体验即可，比如说围绕现有的error机制，增加一些设施以帮助gopher更好的获取error cause信息，就像github.com/pkg/errors包那样。

对于社区呼声很高的generics（泛型），我个人倒是没有什么急切需求。generics虽然可以让大幅提升语言的表现力(expressiveness)，但也给语言自身带来了较大的复杂性。就个人感受而言，C++就是在加入generics后才变得无比庞大和复杂的，同时generics还让很多C++ programmer沉溺于很多magic trick中无法自拔，这对于以“合作分工”为主流的软件开发过程来说，并不是好事情。

6、Go 官方团队已发布 2.0 计划，更侧重于兼容性和规模化方面。对此，您怎么理解？Go 否已达到最佳性能？

这个问题和上面的问题有些类似，我的想法差不多。Go team在特性演进方面会十分谨慎，这也是go Team一贯的风格。从Go1到Go2，从现在看来，这个时间跨度不会很短，也许是2-3年也不一定，心急吃不了热豆腐^0^，社区分裂可不是go team想看到的事情，python可是前车之鉴。

另外，Go性能显然还是有改善空间的，尤其是编译性能、GC吞吐和延迟的tradeoff方面；另外goroutine调度器算法方面可能还有改进空间。当前Goroutine调度算法的实现者Dmitry Vyukov之前就编写了一个scheduler优化的proposal: NUMA-aware scheduler for Go(针对numa体系的优化)，但也许因为重要性、优先级等考量，一直没有实现，也许后续会实现。

7、Go 在国内似乎比国外还要火，您认为造成这种现象的原因是什么？

从一些搜索引擎的trend数据来看，Go在中国地区的确十分火热，甚至在热度值上是领先于欧美世界的。个人觉得造成这种现象的原因可能有如下几点：

• 语言本身的接受度高

首先，从Go语言本身考虑。事实证明了：Go语言的设计匹配了国内程序员的行业业务需求和对语言特性的需求(口味)：
a) 语言：简单、正交组合和并发；开发效率和运行效率双高；
b) 自带battery：丰富的标准库和高质量第三方库；
c) 迎合架构趋势：天生适合微服务….

• 引入早且与Go advocator的努力分不开

当前再也不是那个“酒香不怕巷子深”的年代了，再好的编程语言也需要推广和宣称。Go team在社区建设、全世界推广方面也是不遗余力。至于国内更是有像许式伟、Astaxie这样的占据高端IT圈子的advocator在站台宣传。

• 互联网飞速发展推动Go在国内落地

中国已经是事实的移动互联网时代的领军者，大量创业公司如雨后春笋般诞生。而Go对于startup企业来说是极其适合的。开发效率高，满足了Startup企业对产品或服务快速发布的需求；运行效率高可以让startup公司节省初期在硬件方面的投入：一台主机顶住100w并发。

对于那些巨头、大公司而言，Go又是云计算时代基础设施的代表性语言，自然也会投入到Go怀抱，比如：阿里CDN、百度门户入口、滴滴、360等。

8、对于刚开始学习 Go ，并期待将其应用在项目中的新人们，您有哪些建议？

学语言，无非实践结合理论。

• 理论：书籍和资料

这里转一下我在知乎上一个回答：

强烈推荐：Rob Pike 3-day Go Course，虽然语法过时了，但看大师的slide，收获还是蛮多的。

Go基础: Go圣经《The Go Programming Language》和《Go in Action》。
原理学习: 雨痕的《Go学习笔记》。
Go Web编程: 直接看astaxie在github上的《Go web编程》。

还有一本内容有些旧的，但个人觉得值得一看的书就是《The Way To Go》，大而全。Github上有部分章节的中译版。

另外，建议看一遍官方的Language specification、effective go和go faq，对学go、理解go设计的来龙去脉大有裨益。

• 实践：多读多写Code

多读代码：首选标准库，因为Go的惯用法和最佳实践在标准库中都有体现。

写代码：这个如果有项目直接实践那是非常的幸福；否则可以从改写一个自己熟悉领域的工具开始。比如：以前我刚接触Go的时候，没啥可写的。就改写一套cmpp协议实现。后来做wechat接口，实现了一个简单的wechat基本协议，当然这两个代码也过于陈旧了，代码设计以及其中的go语言用法不值得大家学习了^0^。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

一、序

今天我要分享的题目是“Go coding in go way”，中文含义就是用“Go语言编程思维去写Go代码”。看到这个题目大家不禁要问：究竟什么是Go语言编程思维呢？关于什么是Go语言变成思维其实并没有官方说法。这里要和大家交流的内容都是基于Go诞生七年多以来我个人对Go的设计者、Go team以及Go主流社区的观点和代码行为的整理、分析和总结。希望通过我的这次“抛砖引玉”，让在座的Gopher们对“Go语言编程思维”有一个初步的认知，并在日常开发工作中遵循Go语言的编程思维，写出idiomatic的Go代码。

二、编程语言与编程思维

1、大师的观点

在人类自然语言学界有一个很著名的假说：”萨丕尔-沃夫假说“，这个假说的内容是这样的：

语言影响或决定人类的思维方式("Language inuences/determines thought" - Sapir-Whorf hypothesis )

说到这个假说，我们不能不提及在2017年初国内上映了一部口碑不错的美国科幻大片《降临》，这部片子改编自雨果奖获得者华裔科幻小说家Ted姜的《你一生的故事》，片中主线剧情的理论基础就是就是“萨丕尔-沃夫假说”。更夸张的是片中直接将该假说应用到外星人语言上，将其扩展到宇宙范畴^_^。片中的女主作为人类代表与外星人沟通，并学会了外星语言，从此思维大变，拥有了预知未来的“超能力”。由此我们可以看出“选择对一门语言是多么的重要”。

奇妙的是，在编程语言界，有位大师级人物也有着与”萨丕尔-沃夫假说”异曲同工的观点和认知。他就是首届图灵奖得主、著名计算机科学家Alan J. Perlis(艾伦·佩利)。他从另外一个角度提出了：

“不能影响到你的编程思维方式的编程语言不值得去学习和使用”

A language that doesn't aect the way you think about programming is not worth knowing.

2、现实中的“投影”

从上述大师们的理论和观点，我们似乎看到了语言与思维之间存在着某种联系。那么两者间的这种联系在真实编程世界中的投影又是什么样子的呢？我们来看一个简单的编程问题：

【问题: 素数筛】

  问题描述：素数是一个自然数，它具有两个截然不同的自然数除数：1和它本身。 要找到小于或等于给定整数n的素数。针对这个问题，我们可以采用埃拉托斯特尼素数筛算法。
  算法描述：先用最小的素数2去筛，把2的倍数剔除掉；下一个未筛除的数就是素数(这里是3)。再用这个素数3去筛，筛除掉3的倍数... 这样不断重复下去，直到筛完为止。

算法动图

下面是该素数筛算法的不同编程语言的实现版本。

C语言版本：

【sieve.c】

void sieve() {
        int c, i,j,numbers[LIMIT], primes[PRIMES];

        for (i=0;i<LIMIT;i++){
                numbers[i]=i+2; /*fill the array with natural numbers*/
        }

        for (i=0;i<LIMIT;i++){
                if (numbers[i]!=-1){
                        for (j=2*numbers[i]-2;j<LIMIT;j+=numbers[i])
                                numbers[j]=-1; /*sieve the non-primes*/
                }
        }

        c = j = 0;
        for (i=0;i<LIMIT&&j<PRIMES;i++) {
                if (numbers[i]!=-1) {
                        primes[j++] = numbers[i]; /*transfer the primes to their own array*/
                        c++;
                }
        }

        for (i=0;i<c;i++) printf("%d\n",primes[i]);
}

Haskell版本：

【sieve.hs】

sieve [] = []
sieve (x:xs) = x : sieve (filter (\a -> not $ a `mod` x == 0) xs)

n = 100
main = print $ sieve [2..n]

Go语言版本：

【sieve.go】

func generate(ch chan<- int) {
    for i := 2; ; i++ {
        ch <- i // Send 'i' to channel 'ch'.
    }
}

func filter(src <-chan int, dst chan<- int, prime int) {
    for i := range src { // Loop over values received from 'src'.
        if i%prime != 0 {
            dst <- i // Send 'i' to channel 'dst'.
        }
    }
}

func sieve() {
    ch := make(chan int) // Create a new channel.
    go generate(ch)      // Start generate() as a subprocess.
    for {
        prime := <-ch
        fmt.Print(prime, "\n")
        ch1 := make(chan int)
        go filter(ch, ch1, prime)
        ch = ch1
    }
}

• C版本的素数筛程序是一个常规实现。它定义了两个数组：numbers和primes，“筛”的过程在numbers这个数组中进行(纯内存修改)，非素数的数组元素被设置为-1，便于后续提取；
• Haskell版本采用了函数递归的思路，通过 “filter操作集合”，用谓词(过滤条件）\a -> not $ a mod x == 0；筛除素数的倍数，将未筛除的数的集合作为参数传递归递给下去；
• Go版本的素数筛实现采用的是goroutine的并发组合。程序从2开始，依次为每个素数建立一个goroutine，用于作为筛除该素数的倍数。ch指向当前最新输出素数所位于的筛子goroutine的源channel，这段代码来自于Rob Pike的一次关于concurrency的分享slide。

3、思考

通过上述这个现实中的问题我们可以看到：面对同一个问题，来自不同编程语言的程序员给出了思维方式截然不同的解决方法：C的命令式思维、Haskell的函数式思维和Go的并发思维。这一定程度上印证了前面的假说：编程语言影响编程思维。

Go语言诞生较晚（2007年设计、2009年发布Go1），绝大多数Gopher(包括我在内)第一语言都不是Go，都是“半路出家”从其他语言转过来的，诸如：C、C++、Java、Python等，甚至是Javascript、Haskell、Lisp等。由于Go语言上手容易，在转Go的初期大家很快就掌握了Go的语法。但写着写着，就是发现自己写的代码总是感觉很别扭，并且总是尝试在Go语言中寻找自己上一门语言中熟悉的语法元素；自己的代码风格似乎和Go stdlib、主流Go开源项目的代码在思考角度和使用方式上存在较大差异。而每每看到Go core team member(比如：rob pike)的一些代码却总有一种醍醐灌顶的赶脚。这就是我们经常说的go coding in c way、in java way、in python way等。出现这种情况的主要原因就是大脑中的原有语言的思维方式在“作祟”。

我们学习和使用一门编程语言，目标就是要用这门语言思维方式去Coding。学习Go，就要用Go的编程思维去写Go代码，而不是用其他语言的思维方式。

4、编程语言思维的形成

人类语言如何影响人类思维这个课题自然要留给人类语言学家去破解。但编程语言如何影响编程思维，每个程序员都有着自己的理解。作为一个有着十几年编程经验的程序员，我认为可以用下面这幅示意图来解释一门编程语言思维的形成机制：

决定编程语言思维的根本在于这门编程语言的价值观！什么是价值观？个人认为：一门编程语言的价值观就是这门语言的最初设计者对程序世界的认知。不同编程语言的价值观不尽相同，导致不同编程语言采用不同的语法结构，不同语言的使用者拥有着不同的思维方式，表现出针对特定问题的不同的行为（具现为：代码设计上的差异和代码风格上的不同），就像上面素数筛那样。比如：

C的价值观摘录：

- 相信程序员：提供指针和指针运算，让C程序员天马行空的发挥
- 自己动手，丰衣足食：提供一个很小的标准库，其余的让程序员自造
- 保持语言的短小和简单
- 性能优先

C++价值观摘录：

- 支持多范式，不强迫程序员使用某个特定的范式
- 不求完美，但求实用（并且立即可用）

此外，从上述模型图，我们可以看出思维和结构影响语言应用行为，这是语言应用的核心；同时存在一个反馈机制：即语言应用行为会反过来持续影响/优化语言结构。我们常用冰山表示一个事物的表象与内涵。如果说某种语言的惯用法idiomatic tips或者best practice这些具体行为是露出水面上的冰山头部，那么价值观和思维方式就是深藏在水面以下的冰山的基座。

三、Go语言价值观的形成与Go语言价值观

从上述模型来看，编程语言思维形成的主导因素是这门编程语言的价值观，因此我们首先来看一下Go语言价值观的形成以及Go语言价值观的具体内容。

Go语言的价值观的形成我觉得至少有三点因素。

1、语言设计者&Unix文化

Go语言价值观形成是与Go的初期设计者不无关系的，可以说Go最初设计者主导了Go语言价值观的形成！这就好比一个企业的最初创始人缔造企业价值观和文化一样。

图中是Go的三位最初设计者，从左到右分别是罗伯特·格瑞史莫、罗伯·派克和肯·汤普逊。Go初期的所有features adoption是需要三巨头达成一致才行。三位设计者有一个共同特征，那就是深受Unix文化熏陶。罗伯特·格瑞史莫参与设计了Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎，罗博·派克在大名鼎鼎的bell lab侵淫多年，参与了Plan9操作系统、C编译器以及多种语言编译器的设计和实现，肯·汤普逊更是图灵奖得主、Unix之父。关于Unix设计哲学阐述最好的一本书莫过于埃瑞克.理曼德(Eric S. Raymond)的《UNIX编程艺术》了，该书中列举了很多unix的哲学条目，比如：简单、模块化、正交、组合、pipe、功能短小且聚焦等。三位设计者将Unix设计哲学应用到了Go语言的设计当中，因此你或多或少都能在Go的设计和应用中找到这些哲学的影子。

2、遗传基因

Go并发模型CSP理论的最初提出者Tony Hoare曾提出过这样一个观点：

The task of the programming language designer " is consolidation not innovation ". (Tony Hoare, 1973).
编程语言设计者的任务不是创新，而是巩固。

和其他语言一样，Go也是站在巨人肩膀上的。这种基因继承，不仅仅是语法结构的继承，还有部分价值观的继承和进一步认知改进。当然不可否认的是Go也有自己的微创新，比如： implicit interface implementation、首字母大小写决定visibility等。虽然不受学院派待见，但把Go的这些微创新组合在一起，你会看到Go迸发出了强大的表现力。

3、面向新的基础设施环境和大规模软件开发的诸多问题

有一种开玩笑的说法：Go诞生于C++程序的漫长compile过程中。如果c++编译很快，那么上面的Go语言三巨头也没有闲暇时间一起喝着咖啡并讨论如何设计一门新语言。

面对时代变迁、面对新的基础设施环境、多核多处理器平台的出现，很多传统语言表现出了“不适应”，这直接导致在开发大规模软件过程中出现了各种各样的问题，比如：构建缓慢、依赖失控、代码风格各异、难用且复杂无法自动化的工具、跨语言构建难等。Go的设计初衷就是为了面向新环境、面向解决问题的。虽然这些问题不都是能在语言层面解决的，但这些环境和问题影响了设计者对程序世界的认知，也就影响了Go的价值观。

4、Go语言的价值观

在明确了Go价值观的形成因素后，我认为Go语言的价值观至少包含以下几点：

 - Overall Simplicity 全面的简单
 - Orthogonal Composition 正交组合
 - Preference in Concurrency 偏好并发

用一句话概括Go的价值观（也便于记忆）：

Go is about orthogonal composition of simple concepts with preference in concurrency.
Go是在偏好并发的环境下的简单概念/事物的正交组合

无论是Go语言设计还是Go语言使用，都受到上述价值观的影响。接下来我们逐个来看一下Go语言价值观主导下的Go语言编程思维，并看看每种编程思维在语言设计、标准库实现以及主流Go开源项目中的应用体现。我将按“价值观” -> “(价值观下的)语言设计” -> “编程思维” -> “编程思维体现”的顺序展开。

四、Overall Simplicity

Go的第一个价值观就是”全面简单”。

图灵奖获得者迪杰斯特拉说过：”简单和优雅不受欢迎，那是因为人们要想实现它们需要更努力地工作，更多自律以及领会更多的教育。” 而Go的设计者们恰恰在语言设计初期就将复杂性留给了语言自身的设计和实现阶段，留给了Go core team，而将简单留给了gopher们。因此，Simplicity价值观更多地体现在了Go语言设计层面。 这里简单列举一些：

- 简洁、正规的语法：大大降低Go入门门槛，让来自其他语言的初学者可以轻松使用Go语言；
- 仅仅25个keyword：主流编程语言中最简单的，没有之一；
-  “一种”代码写法、尽可能减少程序员付出;
- 垃圾回收GC: 降低程序员在内存管理方面的心智负担；
- goroutine：提供最简洁的并发支持；
- constants：对传统语言中常量定义和使用方法做进一步简化；
- interface：纯方法集合，纯行为定义，隐式实现；
- package：Go程序结构层面的唯一组织形式，它将设计、语法、命名、构建、链接和测试都聚于一包中，导入和使用简单。

如今，Go语言的简单已经从自身设计扩展到Go应用的方方面面，但也正是由于在语言层面已经足够简单了，因此在应用层面，“简单”体现的反倒不是很明显，更加顺其自然。接下来，我总结整理几个在“全面简单”价值观下形成的Go编程思维，我们一起看一下。

1、short naming thought（短命名思维）

在gofmt的帮助下，Go语言一统coding style。在这样的一个情形下，naming成了gopher们为数不多可以“自由发挥”的空间了。但对于naming，Go有着自己的思维：短命名。即在并不影响readablity的前提下，尽可能的用长度短小的标识符，于是我们经常看到用单个字母命名的变量，这与其他一些语言在命名上的建议有不同，比如Java建议遵循“见名知义”的命名原则。

Go一般在上下文环境中用最短的名字携带足够的信息，我们可以对比一下Java和Go：

   java    vs. go

  "index" vs. "i"
  "value" vs. "v"

除了短小，Go还要求尽量在一定上下文中保持命名含义的一致性，比如：在一个上下文中，我们声明了两个变量b，如果第一个b表意为buf，那么后续的b也最好是这个含义。

在命名短小和一致性方面，stdlib和知名开源项目为我们做出表率。我们统计一下Go标准库中标识符使用频率，可以看到大量单字母命名的变量标识符占据top30：

cat $(find $GOROOT -name '*.go') | indents | sort | uniq -c | sort -nr | sed 30q
          60224 v
          42444 err
          38012 t
          33386 x
          33302 i
          33277 b
          27943 p
          25121 s
          21228 n
          20831 r
          20634 _
          19236 c
          17056 y
          12850 f
          12834 a
          ... ...

细致分析了一下stdlib中常见短变量名字所代表的含义（见代码后的注释），stdlib在一致性方面做的还是不错的，当然也有例外。

        [v, k, i]

        // loop varible
        for i, v := range s {
        for k, v := range m {
        for v := range r { // channel

        // if、switch/case clause varible
        if v := mimeTypes[ext]; v != "" {
        switch v := ptr.Elem(); v.Kind() {
        case v := <-c:

        v := reflect.ValueOf(x) // result of reflect.Value()

        [t]

        t := time.Now() // time
        t := &Timer{ // timer
        if t := md.typemap[off]; t != nil { // type

        [b]

        b := make([]byte, n) // bytes slice
        b := new(bytes.Buffer) // bytes.Buffer

2、minimal thought（最小思维)

码农们是苦逼的，每天坐在电脑前一坐就是10多个小时，自己的“业余”时间已经很少了。Go语言的设计者在这方面做的很“贴心”，考虑到为了让男Gopher能有时间撩妹，女Gopher能有时间傍帅哥，Go语言倡导minimal thought，即尽可能的降低gopher们的投入。这种思维体现在语言设计、语言使用、相关工具使用等多个方面。比如：

• 一种代码风格：程序员们再也无需为coding style的个人喜好而争论不休了，节省下来的时间专心做自己喜欢的事情:)
• “一种”代码写法(或提供最少的写法、更简单的写法)：你会发现，面对一个问题，大多数gopher们给出的go实现方式都类似。这就是Go“一种代码写法”思维的直接体现。Go在语法结构层面没有提供给Gopher很大的灵活性。Go is not a “TMTOWTDI — There’s More Than One Way To Do It”。这点与C++、Ruby有着很大不同。
• 显式代码（obvious），而不是聪明(clever)代码：Go提倡显而易见、可读性好的代码，而非充满各种技巧或称为“炫技”的所谓“聪明”代码。纵观stdlib、kubernetes等go代码库，都是很obvious(直观)的go code，clever code难觅踪迹。这样一来，别人写的代码，你可以轻松地看懂（为你节省大量时间和精力）。这也是Go代码中clever code比例远远小于其他主流语言的原因，Go不是炫技的舞台。

C++程序员看到这里是不是在“抹眼泪”，这里并非黑C++，C++的复杂和多范式是客观的，C++98标准和C++17标准的差异甚至可以用“两门语言”来形容，用泛型的代码和不用泛型的代码看起来也像是两门完全不同的语言，这种心智负担之沉重可想而知。

接下来，我们看看minimal thought在语言设计和应用中的体现。

1) “一种”循环: for

Go语言仅仅提供了一种用于“循环逻辑”的关键字：for。在其他语言中的各种用于循环逻辑的关键字，比如while, do-while等，在go中都可以通过for模拟实现。

- 常规
  for i := 0; i < count; i++ {}

- "while"
  for condition { }

- "do-while"
  for { // use "for-break" instead
        doSomething()
        if condition { break }
  }

- iterator loop
  for k, v := range f.Value {}

- dead loop
  for {}

2) “一种”constant

前面说过Go设计者是十分体贴的，这种体贴体现在很多不起眼的细节上，比如对传统语言中constant声明和使用的优化。

Go语言中constants只是数字，无论是整型还是浮点型都可以直接写成数字，无需显式地赋给类型：

  const incomingQueueLength = 25

  const (
      http2minMaxFrameSize = 1 << 14
      http2maxFrameSize    = 1<<24 - 1
  )

  const PI = 3.1415928
  const e = 1E6

参与计算的constant无需显式算术转换，而是由编译器自动确定语句中constant的承载类型：

  const a = 10080
  var c int32 = 99
  d := c + a
  fmt.Printf("%T\n", d) //int32
  fmt.Printf("%T\n", a) //int

3) “一种”错误处理方法

C++之父Bjarne Stroustrup说过：“世界上有两类编程语言，一类是总被人抱怨诟病的，而另外一类是无人使用的”。Go语言自其出生那天起，就因错误处理机制看起来似乎有些过时、有些简单而被大家所诟病，直至今天这种声音依旧存在。因为Go仅仅提供了一种基于值比较的简单的错误处理方法。但就是这样的错误处理方法也恰恰是Go设计者simplicity价值观的体现。Go设计者认为如果像其他一些主流语言那样，将exception的try-catch-finally的机制与语言的控制结构耦合在一起，将势必大大增加语言的复杂性，这与simplicity的价值观是背道而驰的。简单的基于值比较的error处理方法可以让使用者更重视每一个error并聚焦于错误本身。显式地去处理每一个error，让gopher对代码更有自信。并且在这种机制下，错误值和其他类型的值地位是一样的，错误处理代码也是普通代码，并无特殊之处，无特殊化处理，无需增加语言复杂性。

这些年来，gopher们也初步探索出了这种错误处理方法的常见处理模式，我们以stdlib中识别出的error handling模式为例：

a) 最常见的

在外部无需区分返回的错误值的情况下，可以在内部通过fmt.Errorf或errors.New构造一个临时错误码并返回。这种错误处理方式可以cover 80%以上情形：

    callee:
    return errors.New("something error")

    or

    return fmt.Errorf("something error: %s", "error reason")

  caller:
    if err != nil {... }

b) 导出的Error变量

当外部需要区分返回的错误值的，比如这里我要进行一个io调用，后续的操作逻辑需要因io调用的返回错误码的不同而异，我们使用导出的error变量：

  // io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrShortBuffer = errors.New("short buffer")

  if err := doSomeIO(); err == io.ErrShortWrite { ... }

c) 定义新的错误类型实现定制化错误上下文

上面的导出Error变量中包含的error context信息和信息形成机制太过简单，当我们要定制error context时， 我们可以定义一个新的Error type。之后通过针对error interface value的type assertion or type switch得到真实错误类型并访问error context：

  // encoding/json/decode.go
  type UnmarshalTypeError struct {
      Value  string       // description of JSON value - "bool", "array", "number -5"
      Type   reflect.Type // type of Go value it could not be assigned to
      Offset int64        // error occurred after reading Offset bytes
      Struct string       // name of the struct type containing the field
      Field  string       // name of the field holding the Go value
  }

  func (e *UnmarshalTypeError) Error() string {
      ... ...
      return "json: cannot unmarshal " + e.Value + " into Go value of type " + e.Type.String()
  }

  if serr, ok := err.(*UnmarshalTypeError); ok {
     //use serr to access context in UnmarshalTypeError
     ... ...
  }

不过这样的用法并不推荐也并不多见，在stdlib、kubernetes中，虽然都有自定义的exported error type，但是却很少在外部通过type assertion直接访问其内部error context字段，那标准库是怎么判断error差别的呢？

**d) 包含package中error公共行为特征的Error interface type

在标准库中，我们可以发现这样一种错误处理方式：将某个包中的Error Type归类，统一提取出一些公共行为特征，并且将这些公共行为特征(behaviour)放入一个公开的interface type中。以stdlib中的net package为例。net package将包内的所有错误类型的公共特征抽象放入”Error”这个error type中。外部使用时，通过这个公共interface获取具体错误的特征：

//net/net.go
  type Error interface {
      error
      Timeout() bool   // Is the error a timeout?
      Temporary() bool // Is the error temporary?
  }

net/http/server.go中的使用举例：

  rw, e := l.Accept()
  if e != nil {
      if ne, ok := e.(net.Error); ok && ne.Temporary() {
         ... ..
      }
      ... ...
  }

OpError是net packge中的一个自定义error type , 它实现了Temporary interface, 可以被外部统一用Error的method判断是否是Temporary或timeout error特征：

  //net/net.go
  type OpError struct {
      ... ...
      // Err is the error that occurred during the operation.
      Err error
  }

  type temporary interface {
      Temporary() bool
  }

  func (e *OpError) Temporary() bool {
    if ne, ok := e.Err.(*os.SyscallError); ok {
        t, ok := ne.Err.(temporary)
        return ok && t.Temporary()
    }
    t, ok := e.Err.(temporary)
    return ok && t.Temporary()
  }

**e) 通过一些公开的error behaviour function对error behaviour进行判断

我们在标准库中还能看到一种判断error behavior的方法，那就是通过一些公开的error behaviour function。比如：os包暴露的IsExist等函数：

  //os/error.go

  func IsExist(err error) bool {
      return isExist(err)
  }
  func IsNotExist(err error) bool { ... }
  func IsPermission(err error) bool { ... }

  例子：

    f, err := ioutil.TempFile("", "_Go_ErrIsExist")
    f2, err := os.OpenFile(f.Name(), os.O_RDWR|os.O_CREATE|os.O_EXCL, 0600)
    if os.IsExist(err) {
        fmt.Println("file exist")
        return
    }

顺便在这里提一下Go关于error type和variable的命名方式：

 错误类型: xxxError

  //net/net.go
  type OpError struct { ... }
  type ParseError struct { ... }
  type timeoutError struct{}

导出的错误变量: ErrXxx

  //io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrNoProgress = errors.New("multiple Read calls return no data or error")

很多人抱怨，当前Go提供的error handling方案让gopher可以很容易地写出如下面所示的不优雅代码：

  var err error
  err = doSomethingA()
  if err != nil {
      return err
  }

  err = doSomethingB()
  if err = nil {
      return err
  }

  err = doSomethingC()
  if err = nil {
      return err
  }
  ... ...

代码中大量重复着if err!= nil { return err} 这段snippet。但是如果你全面浏览过Go标准库中的代码，你会发现像上面这样的代码并不多见。Rob Pike曾经在《errors are values》一文中针对这个问题做过解释，并给了stdlib中的一些消除重复的方法：那就是将error作为一个内部状态：

  //bufio/bufio.go
  type Writer struct {
      err error
      buf []byte
      n   int
      wr  io.Writer
  }
  func (b *Writer) Write(p []byte) (nn int, err error) {
      if b.err != nil {
          return nn, b.err
      }
      ... ...
  }

  //writer_demo.go
  buf := bufio.NewWriter(fd)
  buf.WriteString("hello, ")
  buf.WriteString("gopherchina ")
  buf.WriteString("2017")
  if err := buf.Flush() ; err != nil {
      return err
  }

error handling的具体策略要根据实际情况而定。stdlib面向的”业务域”相对”狭窄”，像bufio.Write可以采用上面的方法解决，但是对于做业务应用的gopher来讲，业务复杂多变，错误处理没有绝对的模式，需根据上下文不同而具体设计。但如果一个函数中上述snippet过多，很可能是这个函数或方法的职责过多导致，重构是唯一出路。

五、Orthogonal Composition

正交组合是我总结出来的第二个Go语言的价值观。如果说上一个价值观聚焦的是Go程序提供的各种小概念实体或者说”零件”的话，那么Composition就是在考虑如何将这些”零件”联系到一起，搭建程序的静态骨架。

在Go语言设计层面，Go设计者为gopher提供了正交的语法元素，供后续组合使用，包括：

• Go语言无类型体系(type hierarchy)，类型定义正交独立；
• 方法和类型的正交性: 每种类型都可以拥有自己的method set；
• interface与其实现之间无”显式关联”；

正交性为”组合”策略的实施奠定了基础，提供了前提。Rob Pike曾说过： “If C++ and Java are about type hierarchies and the taxonomy(分类）of types, Go is about composition.”。组合是搭建Go程序静态结构的主要方式。“组合”的价值观贯穿整个语言设计和语言应用：

• 类型间的耦合方式直接影响到程序的结构；
• Go语言通过“组合”构架程序静态结构；
• 垂直组合(类型组合)：Go通过 type embedding机制提供；
• 水平组合：Go通过interface语法进行“连接”。

interface是水平组合的关键，好比程序肌体上的“关节”，给予连接“关节”的两个部分各自“自由活动”的能力，而整体上又实现了某种功能。

1、vertical composition thought(垂直组合思维)

传统OO语言都是通过继承的方式建构出自己的类型体系的，但Go语言中并没有类型体系的概念。Go语言通过类型的垂直组合而不是继承让单一类型承载更多的功能。由于不是继承，那么也就没有了所谓“父子类型”的概念，也没有向上、向下转型(type casting)；被嵌入的类型也不知道将其嵌入的外部类型的存在。调用Method时，method的匹配取决于方法名字，而不是类型。

Go语言通过type embedding实现垂直组合。组合方式莫过于以下这么几种：

a) construct interface by embedding interface

  type ReadWriter interface {
      Reader
      Writer
  }

通过在interface中嵌入interface type name，实现接口行为聚合，组成大接口。这种方式在stdlib中尤为常用。

b) construct struct by embedding interface

  type MyReader struct {
      io.Reader // underlying reader
      N int64   // max bytes remaining
  }

c) construct struct by embedding struct

  // sync/pool.go
  type poolLocal struct {
      private interface{}   // Can be used only by the respective P.
      shared  []interface{} // Can be used by any P.
      Mutex                 // Protects shared.
      pad     [128]byte     // Prevents false sharing.
  }

在struct中嵌入interface type name和在struct嵌入struct，都是“委派模式(delegate)”的一种应用。在struct中嵌入interface方便快速构建满足某一个interface的dummy struct，方便快速进行unit testing，仅需实现少数需要的接口方法即可，尤其是针对Big interface时。

struct中嵌入struct，被嵌入的struct的method会被提升到外面的类型中，比如上述的poolLocal struct，对于外部来说它拥有了Lock和Unlock方法，但是实际调用时，method调用实际被传给poolLocal中的Mutex实例。

2、small interface thought(小接口思维)

interface是Go语言真正的魔法。前面提到过，interface好比程序肌体的骨架关节，上下连接着骨架部件。interface决定了Go语言中类型的水平组合方式。interface与其实现者之间的关系是隐式的，无需显式的”implements”声明(但编译器会做静态检查)；interface仅仅是method集合，而method和普通function一样声明，无需在特定位置。

在Go语言中，你会发现小接口（方法数量在1~3）定义占据主流。

  // builtin/builtin.go
  type error interface {
      Error() string
  }

  // io/io.go
  type Reader interface {
      Read(p []byte) (n int, err error)
  }

  // net/http/server.go
  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type ResponseWriter interface {
      Header() Header
      Write([]byte) (int, error)
      WriteHeader(int)
  }

我统计了一下stdlib、k8s和docker里面的interface定义，画出了下面这幅接口个数与接口中method个数关系的折线图：

小接口方法少，职责单一；易于实现和测试，通用性强(如:io.Reader和Writer)，易于组合(如:io.Reader)。不过要想在业务领域定义出合适的小接口，还是需要对问题域有着透彻的理解的。往往无法定义出小接口，都是由于对领域的理解还不到位，没法抽象到很高的程度所致。

3、horizontal composition thought(水平组合思维)

有了小接口，后续主要关注如何通过接口进行“连接”的方式实现水平组合，以解决大问题、复杂的问题。通过interface进行组合的一种常见方法就是：通过接受interface类型参数的普通function进行组合。

以下几种具体形式：

a) 基本形式

接受interface value作为参数是水平组合的基本形式：

形式：someFunc(interface value parameter)

隐式的interface实现会不经意间满足：依赖抽象、里氏替换原则、接口隔离等原则，这在其他语言中是需要很”刻意”的设计谋划的，但在Go interface来看，一切却是自然而然的。

  func ReadAll(r io.Reader) ([]byte, error)
  func Copy(dst Writer, src Reader) (written int64, err error)

b) wrapper function

形式：接受interface类型参数，并返回与其参数类型相同的返回值

  // Wrapper function:
  func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n} }

  type LimitedReader struct {
      R Reader // underlying reader
      N int64  // max bytes remaining
  }
  func (l *LimitedReader) Read(p []byte) (n int, err error) {}

  // Usage:
  r := strings.NewReader("some io.Reader stream to be read\n")
  lr := io.LimitReader(r, 4)
  if _, err := io.Copy(os.Stdout, lr); err != nil {
      log.Fatal(err)
  }
  // Output: some

LimitReader是一个wrapper function，它在r的外面再包裹上LimitedReader。通过wrapper function将NewReader和LimitedReader 的两者巧妙的组合在了一起。这样当我们采用包装后的reader去Read时，返回的是受到Limitedreader限制的内容了：即只读取了前面的4个字节：”some”。

c) wrapper function chain

由于wrapper function返回值类型与parameter类型相同，因此wrapper function可以组合一个chain，形式如下：

形式：wrapperFunc(wrapperFunc(wrapperFunc(...)))

我们定义一个wrapper function：CapReader，用于将从reader读取的数据变为大写：

  func CapReader(r io.Reader) io.Reader {
      return &capitalizedReader{r: r}
  }

  type capitalizedReader struct {
      r io.Reader
  }

  func (r *capitalizedReader) Read(p []byte) (int, error) {
      n, err := r.r.Read(p)
      if err != nil {
          return 0, err
      }

      q := bytes.ToUpper(p)
      for i, v := range q {
          p[i] = v
      }
      return n, err
  }

将多个wrapper function串在一起：

  s := strings.NewReader("some io.Reader stream to be read\n")
  r := io.TeeReader(CapReader(io.LimitReader(s, 4)), os.Stdout)
  b, _ := ioutil.ReadAll(r) //SOME
  fmt.Println(len(b))       //4

可以看到例子中，我们将TeeReader、CapReader、LimitedReader、strings Reader等组合到了一起，实现了读取前四个字节，将读取数据转换为大写并输出到标准输出的功能。

**d) adapter function type **

adapter function type是一个辅助水平组合实现的“工具”。adapter function type将一个普通function转换为自己的类型，同时辅助快速实现了某个“one-method” interface。 adapter function type的行为模式有些像电影中的“僵尸” – 咬别人一口就可以将别人转化为自己的同类。最著名的僵尸类型莫过于http.HandlerFunc了：

  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type HandlerFunc func(ResponseWriter, *Request)

  func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
      f(w, r)
  }

  // Usage: use HandlerFunc adapts index function to an implemenation type of Handler interface.
  func index(w http.ResponseWriter, r *http.Request) {
      fmt.Fprintf(w, "Welcome!")
  }

  http.ListenAndServe(":8080", http.HandlerFunc(index))

可以看到通过HandlerFunc，我们可以将普通function index快速转化为满足Handler interface的type。一旦转化ok，便可以通过interface进行组合了。

**e) middleware composition **

middleware这个词的含义可大可小，在Go Web编程中，常常指的是一个满足Handler interface的HandlerFunc类型实例。实质上：

middleware =  wrapper function + adapter function type

我们可以看一个例子：

  func logHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          t := time.Now()
          log.Printf("[%s] %q %v\n", r.Method, r.URL.String(), t)
          h.ServeHTTP(w, r)
      })
  }

  func authHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          err := validateAuth(r.URL.Query().Get("auth"))
          if err != nil {
              http.Error(w, "bad auth param", http.StatusUnauthorized)
              return
          }
          h.ServeHTTP(w, r)
      })
  }

  func main() {
      http.ListenAndServe(":8080", logHandler(authHandler(http.HandlerFunc(index))))
  }

wrapper function（如：logHandler、authHandler）内部利用 adapter function type转化了一个普通function，并返回实现了Handler interface的HandlerFunc类型实例。

六、Preference in Concurrency

Go语言的第三个价值观是偏好并发。如果说interface和组合决定了程序的静态结构组成的话，那么concurrency则影响着程序在执行阶段的动态运行结构。从某种意义上说，Go语言就是关于concurrency和interface的设计!

并发不是并行(paralell)，并发是关于程序结构的，而不是关于性能的。并发让并行更easy，并且通常性能更好;对于程序结构来说，concurrency是一个比interface组合更大的概念。并发是一种在程序执行层面上的组合：goroutines各自执行特定的工作，通过channels+select将goroutines连接起来。原生对并发的支持，让Go语言更适应现代计算环境。并发的存在鼓励程序员在程序设计时进行独立计算的分解。

在语言层面，Go提供了三种并发原语：

• goroutines提供并发执行, 它是Go runtime调度的基本单元；goroutine实现了异步编程模型的高效，但却允许你使用同步范式编写代码，降低心智负担；goroutines被动态地多路复用到系统核心线程上以保证所有goroutines的正常运行。

• channels用于goroutines之间的通信和同步；channel是goroutines间建立联系的主要途径或者说goroutine通过channel耦合/组合在一起，这一点channel的功用有点像Unix pipe。

• select可以让goroutine同时协调处理多个channel操作。

1、concurrency thought(并发思维)

我将“偏好并发”价值观下的思维统称为“并发思维”。并发思维的核心依旧是组合！

采用并发思维进行程序动态结构设计，需要识别和分解出独立的计算单元放入Goroutines执行，并使用channel/select建立Goroutines之间的联系。计算单元的拆解是并发程序设计的重点，拆解没有统一规则，因业务域不同而异，例如：素数筛实现为每个素数建立一个goroutine以筛除素数的倍数。

不过我们可以从建立Goroutines间的“联系”的角度来看一些常见的goroutines间的“关系”模式。我们可以从“退出机制”和“通信联系”两大方面出发考虑。

a) “detached” goroutine

所谓分离的goroutine，即不需要关心它的退出，相当于与父goroutine间“无关系”。这类goroutines启动后与其创建者彻底分离(detached)，生命周期与程序生命周期相同。通常，这类goroutine在后台执行一些特定任务，如：monitor、watcher等。其实现通常采用for-select代码段形式；以timer或event驱动。

Go应用中内置的GC goroutine就是这种类型的：

// runtime/mgc.go
  go gcBgMarkWorker(p) // each P has a background GC G.

  func gcBgMarkWorker(_p_ *p) {
      gp := getg()

      for {
        ... ...
      }
  }

b） “parent-child” goroutine

这类goroutine与detached goroutine正相反，parent需要通知并等待child退出。如果仅通知并等待一个child，我们可以这样做：

parent:

  quit := make(chan string)
  go child(quit)

child:

  select {
    case c := <-workCh:
    // do something
    case <-quit:
    // do some cleanup
    quit<-"done"
  }

parent:

  quit<-"quit"
  <-quit

当需要同时通知多个child goroutine quit时，我们可以通过channel close来实现：

parent:

  quit := make(chan struct{})
  for ... {
    go child(quit) // several child goroutines
  }

child:

  select {
    case c := <-workCh: // do something
    case <-quit: // do some cleanup
    return
  }

parent:

  close(quit)
  time.Sleep(time.Second * 30)

如果parent要获得child的退出状态值，可以自定义quit channel中的元素类型：

  type ExitStatus interface {
      Status() int
  }

  type IntStatus int // an adapter
  func (n IntStatus)Status() int {
    return int(n)
  }

  quit := make(chan ExitStatus) // for each child goroutine

child:

  quit <- IntStatus(2017)

parent:

  s := <-quit
  fmt.Println(s.Status()) //2017

c) service handle

一些goroutine在程序内部提供特定service，这些goroutine使用channel作为service handle，其他goroutine通过service handle与其通信。

比如：我们经常使用的time.After返回一个service handle：

  //time/sleep.go
  func After(d Duration) <-chan Time {
      return NewTimer(d).C
  }

对应的service goroutine就是runtime中的timer service goroutine：

  // runtime/time.go
  func timerproc() {
    timers.gp = getg()
    for {
      ... ...
    }
  }

编写此类service goroutine时，需要考虑对于“慢消费者”service goroutine应该如何处置：阻塞还是丢弃。timer service goroutine使用的是buffered channel(size=1)，并在向channel发送消息时通过select做了一个判断。如果channel buffer满了，则丢弃这次timer事件。

如果我们要同时处理来自不同service goroutine的handle，那么可以使用service handles aggregation，见下面例子：

比如：我们从wechat、weibo、短信渠道获取msg：

  type msg struct {
      content string
      source  string
  }

  func wechatReceiver() <-chan *msg {
      c := make(chan *msg)
      go func() {
          c <- &msg{"wechat1", sourceWechat}
          c <- &msg{"wechat2", sourceWechat}
          c <- &msg{"wechat3", sourceWechat}
      }()

      return c
  }

  func weiboReceiver() <-chan *msg {...}
  func textmessiageReceiver() <-chan *msg {...}

我们需要把这些handle聚合起来统一处理，我们通过一个aggregation function来做。对于不固定数量handles的聚合，用goroutine来聚合(非常类似于unix pipe chain)：

  func serviceAggregation(ins ...<-chan *msg) <-chan *msg {
      out := make(chan *msg)
      for _, c := range ins {
          go func(c <-chan *msg) {
              for v := range c {
                  out <- v
              }
          }(c)
      }
      return out
  }

  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

对于固定数量handles聚合，用select就可以实现：

  func serviceAggregation(weibo, wechat, textmessage <-chan *msg) <-chan *msg {
      out := make(chan *msg)

      go func(out chan<- *msg) {
          for {
              select {
              case m := <-weibo:
                  out <- m
              case m := <-wechat:
                  out <- m
              case m := <-textmessage:
                  out <- m
              }
          }
      }(out)
      return out
  }
  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

d) dispatch-and-mix goroutines

在“微服务”时代，我们在处理一个请求时经常调用多个外部微服务并综合处理返回结果：

  func handleRequestClassic() {
    r1 := invokeService1()
    //handle result1
    r2 := invokeService2()
    //handle result2
    r3 := invokeService3()
    //handle result3
  }

上述例子中的问题是显而易见的：顺序调用、慢、一旦某个service出现异常，返回时间不可预知，可能会导致调用阻塞。

一个优化的方法就是讲将处理请求时对外部的服务调用分发到goroutine中，再汇总返回结果。并且通过设置一个总体超时时间，让调用返回的时间可预知。：

  func handleRequestByDAM() {
    c1, c2, c3 := make(chan Result1), make(chan Result2), make(chan Result3)
    go func() { c1 <- invokeService1() } ()
    go func() { c2 <- invokeService2() } ()
    go func() { c3 <- invokeService3() } ()
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
            c1 = nil
        case r := <-c2: //handle result2
            c2 = nil
        case r := <-c3: //handle result3
            c3 = nil
        case <-timeout:
            fmt.Println("timed out")
            return
        }
    }
    return
  }

不过这次优化后的程序依旧存在一个问题，那就是一旦timeout，调用返回，但一些在途的请求资源可能没有回收，request无法显式撤回，久而久之，可能导致资源的泄露。于是我们做进一步改进：通过Context显式cancel掉已经向外发起的在途请求，释放占用资源:

  type service func() result
  func invokeService(ctx context.Context, s service) chan result {
    c := make(chan result)
    go func() {
      c1 := make(chan result)
      go func() {
        c1 <-s()
      }
      select {
        case v := <-c1:
             c <-v
        case <-ctx.Done():
        // cancel this in-flight request by closing its connection.
      }
    }()
    return c
  }

  func handleRequestByDAM() {
    ctx, cf := context.WithCancel(context.Background())
    c1, c2, c3 := invokeService(ctx, service1), invokeService(ctx, service2),
                   invokeService(ctx, service3)
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
        case r := <-c2: //handle result2
        case r := <-c3: //handle result3
        case <-timeout:
            cf() // cancel all service invoke requests
            return
        }
    }
    return
  }

优化后的程序的优点：并发、快、返回结果可预知。

七、总结

通过这篇文章，我总结了主导Go语言编程思维的三个价值观：

• Overall Simplicity
• Orthogonal Composition
• Preference in Concurrency

阐述了每种价值观主导下的编程思维，并给出了每种编程思维在语言设计、语言应用方面的一些模式和实际例子。

Go最初的设计初衷还有一点，那就是将编程时的fun重新带给Gopher们。但个人觉得只有当你使用Go编程思维去写Go code时，你才能体会到Go设计者的用意，才能让你没有别扭的赶脚，发现自己走在正确的way上，才能真正感到go coding时的fun。

另外，虽然总结出的三个价值观数量不多，但如果能在实际运用中认真践行，却能迸发巨大能量。它会让你应对各种复杂情况、代码设计变得游刃有余、顺利解决各种业务问题。

最后再说说Go 2.0。回到前面的 “编程语言思维的形成”模型，行为总是对结构有反馈的，这将导致结构的持续改变和优化。Go team将于今年8月份发布Go1.9版本，这是一个关键的时间节点。恰好今年的denver的Gophercon大会上，Russ Cox将做”the future of go”的演讲，后续是继续1.10还是Go 2.0，让我们拭目以待！不过个人觉得，无论对语言结构改动的需求有多大，Go的价值观都是不会发生改变的。

本文的slide文件可以在这里下载。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

1、首先介绍一下自己。

大家好！我叫白明（Tony Bai），目前是东软云科技的一名架构师，专职于服务端开发，日常工作主要使用Go语言。我算是国内较早接触Go语言的程序员兼Advocater了，平时在我的博客、微博和微信公众号“iamtonybai”上经常发表一些关于Go语言的文章和Go生态圈内的信息。

在接触Go之前，我主要使用C语言开发电信领域的一些后端服务系统，拥有多年的电信领域产品研发和技术管理经验。我个人比较喜换钻研和分享技术，是《七周七语言》一书的译者之一，并且坚持写技术博客十余年。同时我也算是一个开源爱好者，也在github上分享过自己开发的几个小工具。

目前的主要研究领域包括：Go、Kubernetes、Docker和儿童编程教育等。

2、回忆一下与Golang的渊源。是什么原因决定尝试Golang？自己用Go语言实现的第一个项目是什么？当时 Golang 有什么令人惊喜的表现，又有什么样的小不足，这个不足在Golang已经更新到1.8版本的时候是否已经得到改善？

众所周知，Go语言最初由Robert Griesemer, Ken Thompson和Rob Pike在2007年末共同设计和实现，2009年11月份正式发布并开源，并于2012年3月份发布了1.0版本以及Go1规范。我就是在2012年开始接触Go的，那是缘于看到一份由Rob Pike主讲的3-day Go Course资料。从那份资料里，我了解到了Go的设计理念和Go语法。

由于之前浸淫于C语言多年，深知C语言在系统编程以及服务端编程方面的强大，同时也亲身体会到C的语法“陷阱”和C手工内存管理给开发者带来的苦恼。虽然那些年市面上也有其他主流语言可供选择，但在我看来，它们给我带来的心智负担太过沉重，比如：C++“宇宙无敌”的学习和使用复杂性、Java超大的资源消耗和庞大且纷繁芜杂的框架体系、动态语言（ruby、python）无静态类型而导致运行时crash时调试的困难、函数式语言（如Haskell、clisp）的过于小众和非主流。显然它们都不是我的菜。直到Go的出现，C程序员出身的我一下子就被这门新语言迷住了。

现在想起这件事来，我当时迷上Go应该主要由于以下几点原因：

* 静态类型语言、接近于C的性能(对于C程序员来说，这算是某种天然继承性)
* 简洁的语法
* 内置的并发支持
* GC
* 贯穿整个语言的正交设计和组合编程思路（兼容对OO的支持）
* 工具和功能全面的标准库

而且这几点也是这几年持续支撑我深入学习和使用Go语言的原因。

不过由于Go1刚出来时也十分小众，并且各方面功能还在完善中，我并没有在真实项目中使用Go，这种状况一直持续到2014年末。直到那时，我才在一个小项目中使用Go实现了一个微信公众号的协议接口。当时发现：使用Go实现一些安全协议真是非常方便，因为标准库里内置了很好的支持，比如：各种aes、sha256、tls算法实现。同时，Go内置的testing framework、gofmt、Go pprof工具的表现也是让我感觉用起来十分舒服。

如果非要说当时有什么不足之处的话，那只能是Go对debugging的支持明显不足。即便是到了目前最新的Go 1.8版本，Go在debugging方面虽然有所改善，但和C这样的传统语言来说依然有很大差距。不过好在我们有“print”这个无敌调试武器，Go的这个不足对我影响微乎甚微^0^。

当然随着Go在更多规模稍大项目的使用，Go的包管理问题逐渐浮出水面，这也是整个Go社区都想改进的事情。好在目前已经有了专门的Commitee来做这件事，最新的roadmap显示dep工具将在Go 1.10 dev cycle并入Go tools中。

3、2009年诞生至今，Go语言基本统治了云计算，作为最专业的Go语言专家，您认为这是由于它的哪些优雅的特性？Golang未来还会有什么样的改进和突破？

“作为最专业的Go语言专家”，这一称号的确不敢当。我觉得我个人只是国内Gopher普通一员，能为Go语言在国内的发展做点事情就很高兴了^0^。

Go自从1.5版本自举后，随着ssa优化、GC延迟优化的深入，Go在国内外的使用趋势确实是一片大好，尤其是Go问鼎2016年TIOBE编程语言排行榜的年度语言，让更多的程序员知道Go语言、了解Go语言和使用Go语言。在云计算成为当今IT行业常态的今天，Go在这方面已然成为一个重量级选手。从个人对Go的情感角度出发，我个人是希望Go语言能成为”21世纪的C语言”和云平台第一语言的。不过这是一个过程，需要时间，还需要依靠全世界Gopher和Go Community的共同努力才能实现的。

时代不同，语言的成长环境也有所不同。和上一代和两代的语言似乎有所不同，新一代编程语言是否能进入程序员们的法眼，是否值得程序员去投资，“背景”很重要，即所谓的编程语言也进入了“拼爹”时代。Go语言背靠Google这棵大树，又有Robert Griesemer, Ken Thompson, Rob Pike三巨头坐镇，是真正的“牛二代”，它自然就会得到不少程序员的青睐。我想这是Go吸引眼球的场外因素。

至于Go本身的语言特性，在上一个问题中，我已经做了初步阐述了，这里再补充几点：

* Go是一门以解决Google内部生产环境中的问题（大规模并发服务）为目标的、兼顾在语言设计层面解决一些软件工程问题的面向大规模并发服务的编程语言；
* 开发效率较高(对比主流的C、C++和Java)，且执行效率与C相比，没有数量级级别的差异；
* 编译速度超快（相对其他需编译的主流语言），无需喝咖啡等待；
* Go1兼容性的承诺。

Go语言到目前已经演进到1.8版本，Go 1.9开发周期已经打开。今年夏天，Go 1.9发布后，Go似乎就到了版本演进的关键节点，是继续Go1兼容（Go 1.10、Go 1.11…），还是诞生Go2规范，目前并没有明确信息。不过未来的改进和突破，我觉得还是应该建立在Go语言设计的初衷和设计原则之上，这些初衷和原则包括：

目标：
 * 高效的静态编译语言
 * 动态语言的易用性
 * 类型安全和内存安全
 * 对并发和通信的良好支持
 * 高效、低/趋于零延迟的GC
 * 高速编译

原则：

 * 保持概念正交
 * 保持语法简单
 * 保持类型系统精炼，无type hierarchy

从这些年Go的发展来看，基本都是遵循以上目标和原则的。即便Go2出来，不符合上述原则的feature，也是很难加入到Go2里面的。

4、之前是否有关注到Gopher China大会，对大会的风格和内容有什么样的印象？

对于中国大陆地区规模最大，最具影响力的Go大会，我是从第一届就开始关注了，虽然第一届因故没能参加^0^。在去年举行的第二届大会，我是作为早鸟观众参与的哦。而本届则有幸成为讲师。

GopherChina从诞生至今，规模日益扩大，据说今年的参会人员可能突破1000人。而且GopherChina大会从第一届就汇聚了国内一线IT厂商的精英技术人员作为讲师，并得到了Go core team的大力支持。在每一届大会都会邀请到Go team中的核心开发人员参会布道，甚至在第一届大会时还邀请到了Go三巨头之一的Robert Griesemer，极大满足了国内Gopher的求知欲。

而且就我观察，每一届GopherChina大会的主题都涵盖：语言、工程、新兴领域应用等多个环节，颇具多样性和全面性。

5、作为讲师也是参会者，对于今年的Gopher China大会的哪些议题有所期待？

GopherChina每一届都是高手云集，这届也不例外。今年大会的每个议题都令我很是期待。

6、现在很多企业项目都在准备转Go，对于这些项目的负责人有没有建议和经验分享？

Go语言以极易上手著称，同时Go也是一门十分简单的语言（相对于其他主流语言），C、Cpp、Java、Python等程序员转型到Go的曲线并不陡峭，因此团队整体转型为Go的门槛并不高。但还是要有几点是项目负责人需要认真考虑的：

(1) 确认Go适合项目的应用场景

Go不是万能的，不能为了用Go而去用Go。但Go从最初定位为一门系统语言(Sytem Programming Language)逐渐演化成为一门通用语言(General Purpose Programming Language)，说明其适应性和应用范围已经十分广泛，目前在云计算、Web开发、大数据、游戏、数据库、IDE、容器等领域均有大规模应用案例。但即便这样，仍然在有些领域的应用需要谨慎，比如嵌入式领域、比如mobile开发，虽然在这两个方面Go都做出了很大的努力，但似乎并没有较大的突破。

(2) 以终为始，从开始就参考Go的最佳实践

Go经过若干年的演化发展，逐渐形成了一些最佳实践，包括：项目代码组织、命名、惯用法、测试方法、错误处理、接口使用等。建议多看官方的talks、blog和世界范围内Go大会的presentation video。

(3) 单元测试全程保障

Go内置了单元测试框架，而单元测试是检验代码设计好坏的基础，也是代码重构的先决条件。建议项目从始至终都要优先考虑对代码编写测试代码。

(4) 充分利用标准库

在Go的应用实践中，你会发现Go标准库已经为你提供了大部分你要使用的功能。甚至有一些极端的Go纯粹主义者只愿意标准库中的函数和方法。Go标准库凝聚了Go team以及相关Contributor的Go代码精华，其稳定性绝对值得信赖。充分和广泛利用标准库也便于项目代码组织、构建和迁移。

(5) 基于go tool建立代码metric视图

对于那些性能敏感的系统，建议在内部环境基于go tool建立起代码的metric视图，监控代码变化给系统性能等带来的影响，利于问题诊断。

最后，请及时反馈Go语言自身问题，你的反馈是Go语言演化的动力。

7、有没有你觉得很酷的Gopher？可以回答自己哟～

在github.com/golang/go上，我经常关注Russ Cox的代码。众所周知，Russ Cox是Go核心代码提交次数最多的member，他也除三巨头之外，对Go演化影响着最大的人之一。从近两年的Go team开发活动来看，Russ Cox开发效率很高，并且提出的proposal思维之缜密和全面令人叹服。

Dave Cheney是另一个我经常关注的Gopher，他也是第二届GopherChina大会的受邀讲师。他不遗余力的“鼓吹”Go，并从Go 1.6版本开始，发起了Go Global release party ，成为Go Community又一个节日。他不仅是Go community中的意见领袖，同时也为Go社区贡献不少有用的工具和思想，包括：gb、errors等。

Dmitry Vyukov，前Intel Black Belt级工程师，现Google员工，虽然他不是专职Go team的人，但他却是Go scheduler当前版本的核心实现者。虽然近两年似乎在golang的投入并不是那么多，但依然成果丰硕，Go Execution Tracer、go-fuzz(据说要加入go核心)都是他的杰作。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

自己一直是“每年学习一门新语言”的忠实拥趸，曾先后认真地学习了Haskell、Common Lisp、Python、Go等语言，对Prolog、Scala、Erlang、Lua、PHP也有一定了解。但几年下来，只有Python一门语言算 是真正被留在我的大脑里，用在了工作中。其他那几门语言留下来的只是一些思想了。这似乎符合了Andy Hunt和Dave Thomas在《程序员修炼之道》中对于这一实践目的的阐述：“学会用多种方式解决问题，扩展我们的视野，避免思路僵化和停滞不前”^_^。

即便是残存的思想，其实也并不深刻。要真正会运用新思维并非那么简单。一门编程语言从入门到精通，至少要经历学语法、做实践、用idioms（写出地道的代码）三个阶段。这让我深刻的感悟到：不以使用为目的的语言学习，都是在浪费生命！

有精力多学习些语言自然很好，我迫切期待能拥有一个像“七龙珠”中孙悟空那样的“精神时光屋”呢。但现实中，人的精力是有限的，而我们要面对的计算机科学领域中的知识、技能以及问题却似乎是无限的。因此在“每年至少学习一门新语言”这一实践上，建议不要过于教条。 从编程语言自身来看，范型(Paradigm)是影响语言思维差异的主要因素，而编程语言的范型有限，主流的也就那么几种：命令式（过程式）、函数式、逻 辑式、面向对象等。每种范型的背后都有几种、十几种甚至几十种语言，我们其实没有必要都去学。从拓展视野的角度去说，从每种主流范式中找到一两门典型的语 言去学习就可以了。比如命令式的，我们可以选择C；函数式我们选择Haskell；逻辑式的选择Prolog；面向对象的选择Java等。

即便是从每个范型中挑出一门，你要付出的精力依旧不少，我们还要考虑其实用性：要以使用为目的。如果能将其用在工作中，天天与你相伴，被他人接受，自然最 好；退而求其次，你能找到一两个开源项目，并参与其中也是可以的，至少可以让你保持手热；如果这两点都无法做到，仅仅是凭借个人的热情与坚持，那是不会持 久的，若干时间后，你就会对其生疏，可能连基本的"Hello World"语法都记不得了。不过这个年头，思想也不能不要。在有剩余精力的前提下，挑选些牛人们极力“鼓吹”的语言，吸收一下其思想精华，说不定哪天就 能用得上，让自己和大家都感觉你很NB，抬高一下自己的身价^_^。记住：编程语言也是要拼爹的，系出名门的语言(诸如Go、Dart等)自然得到更多的青睐、使用和推广，出位的几率也就高出许多，尤其是在目前新编程语言百花齐放的阶段。因此在选择有思想的新语言时，最好在这些名门之后中做优选。

这个时代喜欢“专家”，因此我们在一两门语言上务必要做到“精专”，这是会给你带来黄油和面包的语言。要专到什么程度呢？我有一个同事，什么问题都用C解决。他甚至为此写了个不小的基础框架，所有业务问题的Code放在框架中被回调即可，即便是这个问题用Python实现只需几行代码。

计算机科学的研究核心是什么？我想肯定不是编程语言，就好比社会科学研究的核心不是人类语言一样。我比较欣赏这样的观点：作为程序员而言，最重要的是去创造，而不是研究。我们应更多的利用已经掌握的语言解决现实中的问题。做 编程语言研究的人可能要了解各种语言的特点与实现方式，但对于大多数的程序员来说，其实我们只需要关注问题域：做底层平台开发的，关注机器模型、通信原理 以及OS原理和实现细节；做算法的，很荣幸，那才是正统的程序设计的核心；前端攻城师则更多关注用户的体验。而在这些解决实际问题的过程中，我们更多采用 的是“制式”的编程语言。即做平台开发的，一般用C，C++等系统编程语言，更多的考虑的是性能；做前端开发的，PHP/JavaScript不可或缺。 我们要考虑的是如何利用这些制式的编程语言去解决问题，而在这些制式语言上，我们要做到精通。

从新兴语言中借鉴新思想，然后在旧语言中实现新语言的特性，其实更多是在旧语言中实现了某 种语法糖，你爱吃，不代表其他人也理解也爱吃，还容易被人误认为是“炫技”。如果你是技术负责人，且经过评估，新语言十分适合这个问题域，那莫不入直接引 入这门语言，让大家都能使用到这门语言的新思想、新特性。

辩证的说，任何一种编程语言都有其利与弊，比如Haskell，纯函数式语言，变量不能改变，无状态，对并行处理具有天然的适应性，但在处理基本IO时却要编写难于理解的monad；而在命令式语言中，这种IO处理简直简单的不得了。

关于函数式语言，个人感觉未来若干年内仍难以大行其道，建议还是跟上命令式语言的演化主线吧。

跨越问题域学习语言，通常收获不大。一个做平台服务端，用惯了C的资深程序员，让他去学PHP写前端代码，估计是无法迸发出任何火花的。

以上是自己这些年关于编程语言学习的一些体会，比较零散，但希望能有帮助。

© 2013, bigwhite. 版权所有.