Go - Tony Bai

标签 Go 下的文章

Ghostty 之父带头“出走”GitHub！官方 CTO 紧急道歉，并揭秘正在使用 Go 语言救火

四月 30, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/04/30/ghostty-creator-leads-github-exodus-cto-apology-go-fix

大家好，我是Tony Bai。

在程序员的江湖里，GitHub 从来不仅仅是一个代码托管平台。它是开源精神的麦加，是数千万开发者的“赛博故乡”，是这个行业赖以运转的、最坚实的“基础设施”。

但就在近几个月，这座我们无比信赖的“圣城”，似乎正在走向“崩塌”。

4 月 28 日，Github 的第1299位用户，在自己的推特与博客上发表了一篇极其悲伤的“分手信”，标题是：《Ghostty Is Leaving GitHub》（Ghostty 正在离开 GitHub）。

这位用户，不是别人，正是 HashiCorp 的联合创始人、一手缔造了 Terraform、Vagrant、Vault、Consul 等一系列云原生和 Devops 神器的“教父级”人物——Mitchell Hashimoto。而 Ghostty，正是他当下倾注心血的、备受期待的新一代终端项目。

他在这封信中，用一种近乎“心碎”的口吻写道：

“写下这些让我感到莫名的悲伤。我从 2008 年 2 月开始使用 GitHub，至今已超过 18 年，横跨了我半个人生。……我曾深爱着 GitHub，胜过一个人应该去爱一个东西。但现在，我受够了。18 年了，我得走了。”

是什么，让这位曾经的“ GitHub骨灰粉”毅然决然地带着自己的“亲儿子”项目“出走”呢？

答案简单得令人窒息：GitHub 正在变得越来越不可用。

“在过去的一个月里，我用日记记录了每一次 GitHub 宕机对我工作的影响。几乎每一天，旁边都画着一个‘X’。就在我写下这些文字的时候，GitHub Actions 又挂了 2 个小时。……如果一个平台每天都要瘫痪几个小时，那它就不再是一个适合严肃工作的地方。”

Mitchell 的这封“分手信”，像一颗炸弹，瞬间引爆了整个技术圈。

就在文章发布的几个小时后，GitHub 的 CTO Vlad Fedorov 紧急发表了一篇官方博客，标题同样沉重：《An update on GitHub availability》（关于 GitHub 可用性的更新）。

在这篇近乎“道歉信”的回应中，GitHub 官方不仅承认了问题的严重性，更罕见地揭示了这场“可用性雪崩”背后的真正罪魁祸首，以及他们正在秘密进行的“技术自救”——其中，Go 语言扮演了至关重要的“救火队长”角色。

今天，就让我们来复盘一下这场由“分手信”引发的技术公案。

压垮骆驼的稻草：被 AI “撑爆”的古老架构

GitHub 到底怎么了？

在官方的回应中，CTO Vlad Fedorov 给我们展示了一张极其恐怖的增长曲线图：“Record Acceleration”（创纪录的加速）。

Pull requests、Commits、New repos 数量爆炸式增长的曲线图

自 2025 年下半年以来，随着 AI Agent（智能体）编程工作流的急剧加速，GitHub 的各项核心指标都呈现出近乎垂直的指数级增长：

每月新增仓库数：2000 万
每月合并的 PR 数：9000 万
每月 Commits 数：14 亿

GitHub 官方坦言：

“这种指数级的增长，不是只对一个系统造成压力。一个 PR 会触及 Git 存储、合并检查、分支保护、GitHub Actions、搜索、通知、权限、API、后台任务、缓存和数据库。在巨大的规模下，微小的低效会被无限放大。”

队列加深、缓存击穿、索引落后……这些经典的分布式系统“并发症”，在 AI 制造的流量洪峰面前，被彻底引爆了。

Mitchell Hashimoto 的“出走”，只不过是压垮骆驼的最后一根稻草。

Go 语言的救赎：从 Ruby 单体地狱中“紧急救火”

面对这场史无前例的“流量洪水”，GitHub 的工程师们正在进行一场惊心动魄的“架构自救”。

在官方博客的What we’re doing一小节中，我们看到了一个熟悉的身影——Go 语言。

“我们加速了将性能或规模敏感的代码，从 Ruby 单体应用中迁移到 Go 语言的过程。”

这短短的一句话，信息量巨大。它揭示了 GitHub 这座“上古神殿”最核心的技术债之一：一些庞大、沉重、且难以扩展的 Ruby 单体应用。

在过去，当我们需要提升性能时，可能会选择更深入地优化 Ruby 代码，或者在前面加更多的缓存。

但在 AI 时代，这种“小修小补”可能已经毫无意义了。面对 10 倍甚至 30 倍的流量增长预期，唯一的出路，就是对系统进行“外科手术式”的重构。

为什么选择 Go 来“救火”？

因为 Go 语言几乎是为这种“救火”场景量身定制的：

极致的性能与并发：Go 的性能远超 Ruby，其原生的 Goroutine 并发模型，能极其轻松地榨干现代多核服务器的性能，应对海量的网络请求。
极低的资源占用：相比于 Ruby 或 Python 这种动态语言，Go 的内存占用更小、更可控，能极大地降低服务器成本。
简单的部署：静态编译的单一二进制文件，使得将新的 Go 微服务部署到庞大的 Kubernetes 集群中，变得极其简单。

我们可以想象，在 GitHub 内部，正有无数个由 Go 语言编写的、小而美的微服务，像一支支训练有素的“消防队”，正在冲入火场，小心翼翼地从那个庞大的 Ruby 巨人身上，一块块地切下那些已经“燃烧”的性能瓶颈模块（如 Webhooks、认证授权、Git 操作等）。

Go 语言，正在成为 GitHub 这艘巨轮在 AI 洪流中，避免沉没的“压舱石”。

从“深情”到“决绝”：一个顶级开发者的 18 年之痒

Mitchell 的“分手信”，之所以能在社区引发如此巨大的共鸣，不仅仅是因为他的技术地位，更在于信中那份令人动容的“爱之深，责之切”。

他坦言，自己 20 岁时创建 Vagrant 这个成名作，很大程度上就是为了能获得一份在 GitHub 的工作。

“GitHub 是我的梦想。那里的工程师令人难以置信，产品令人难以置信。在过去的 18 年里，我每天都在呼吸着它的空气。”

“当我的感情经历挫折时，我把自己沉浸在 GitHub 的开源世界里；当我在大学里通宵时，我会在凌晨 4 点偷偷提交一个 commit；甚至在我的蜜月期间，我都会趁着妻子还在睡觉时，打开 GitHub。”

但正是这份深沉的爱，让 GitHub 的每一次宕机，都像一把刀子，刺在他的心上。

“这对我来说是私人的。我对 GitHub 的爱，超过了一个人应该对一个东西的爱。所以我对它感到愤怒。”

在文章的最后，他给所有“Git 是分布式的，你怕什么”的言论，给出了最沉重的回击：

“问题不在于 Git，而在于我们围绕它建立的、赖以为生的基础设施：Issues, PRs, Actions……如果它每天都要让你停工几个小时，那它就不再是一个适合严肃工作的地方。”

小结：当“基础设施”不再是理所当然

Mitchell Hashimoto 的“出走”，和 GitHub 官方的“道歉”，共同为我们揭示了 AI 时代一个极其深刻的现实：

当生产力工具的效率被提升 10 倍、100 倍时，它对底层基础设施稳定性的要求，也将被以同样指数级的规模放大。

我们曾经以为像水和电一样“理所当然”的 GitHub，正在成为整个行业发展的瓶颈。

这场危机，对 GitHub 来说是“生死存亡”的挑战，但对我们这些身处其中的技术人来说，又何尝不是一次“机遇”？

它告诉我们：

基础软件领域，永远有仗可打。 当所有人都涌向应用层，去卷 AI Agent 的花活时，那些能用 Go 或 Rust，去重构和加固底层基础设施的硬核工程师，其价值将变得空前稀缺。
“稳定性”是最高的壁垒。 在一个功能可以被 AI 瞬间生成的时代，一个系统的长期价值，越来越多地体现在它的可用性、可靠性和可扩展性上。
保持警惕，准备“B 计划”。 将所有的鸡蛋都放在 GitHub 这一个篮子里，可能不再是一个明智的选择。无论是自建 GitLab或Forgejo，还是探索其他新兴的代码协作平台，都值得我们重新审视。

旧神正在踉跄，新王尚未诞生。

在这场由 AI 引发的、史无前例的“基础设施大迁徙”中，你，准备好你的船票了吗？

资料链接：

https://mitchellh.com/writing/ghostty-leaving-github
https://github.blog/news-insights/company-news/an-update-on-github-availability/
https://x.com/mitchellh/status/2049213597419774026

今日互动探讨：

在过去几个月里，你是否也曾被 GitHub 的频繁宕机所困扰？你认为 GitHub 这次“中年危机”的根源，真的是 AI 吗？还是其自身技术债的必然爆发？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
构建坚不可摧的 Safety Middleware 与飞书人工审批防线
在底层实现 Token 成本审计、链路追踪与自动化跑分评估
从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

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

Go 1.27 将默认开启 SIMD for amd64，可移植 SIMD 包提案出炉

四月 29, 2026
2 条评论

本文永久链接 – https://tonybai.com/2026/04/29/go-1-27-default-simd-for-amd64-portable-simd-proposal

大家好，我是Tony Bai。

过去十年，Go 语言以其惊人的简洁和强大的并发能力，席卷了整个云原生领域。但在这片繁荣之下，一个尴尬的“阿喀琉斯之踵”，始终困扰着所有追求极致性能的 Gopher：

Go 语言，无法像 C++ 或 Rust 那样，原生且优雅地利用现代 CPU 的 SIMD（单指令多数据流）能力。

当你需要处理海量数据（如向量计算、图像处理、加解密）时，手写 Go 代码的性能，往往会被隔壁 C++/Rust 的 SIMD 优化版本，拉开数倍甚至数十倍的差距。为了榨干 CPU 的最后一滴性能，我们不得不去手写那些极其晦涩、难以维护、且无法被 GC 优雅调度的 Go 汇编。

但就在今年年初发布的Go 1.26版本中，这场长达十年的“性能怨念”，终于迎来了终结的曙光。Go 1.26以实验特性形式在AMD64架构上提供了SIMD的支持。

近期，Go 核心团队在官方 GitHub 仓库中，又密集地抛出了一系列重磅提案（#78902, #78979等）。这些提案不仅宣告了在 Go 1.26 中实验性加入的 SIMD 功能大获成功，更进一步宣布： 在即将到来的 Go 1.27 中，simd/archsimd 包将默认开启！同时，一个早已规划好的、架构无关的“可移植（Portable）”SIMD API 也已正式提案！

Go 团队试图用一种极其“Go-like”的优雅方式，为我们揭开 SIMD 这头性能怪兽的封印。

今天，就让我们来拆解这场 Go 语言的“性能下半场”革命，看看 Go 团队到底在下一盘怎样的大棋。

Go 的 SIMD 哲学：syscall vs os 的“两层模型”

要理解 Go 的 SIMD 设计，我们必须先看懂官方在 Issue #73787 中提出的核心哲学——“两层模型（Two-level approach）”。

Go 团队清醒地认识到，SIMD 的世界充满了矛盾：

底层：硬件指令集是非可移植的（Non-portable）。AMD64 上的 AVX512、ARM 上的 NEON/SVE、Wasm 里的 SIMD，它们的向量宽度、指令名称、甚至掩码（Mask）的表示方式都截然不同。
上层：Go 语言的核心魅力，恰恰是它的可移植性（Portability）。一份代码，处处运行。

如何调和这个矛盾？Go 团队从标准库中 syscall 和 os 包的关系里，找到了灵感。

第一层：simd/archsimd —— 你的“syscall”

这一层，是架构绑定的、低级别的。它将 CPU 的 SIMD 指令，近乎一对一地封装成 Go 的函数。比如 VPADDD 指令，就对应着 Uint32x4.Add()。

这一层追求的是极致的表达力和与硬件的零距离。它就是为那些需要手写汇编的“性能狂人”准备的。如果你想调用某个 AVX512 的独有指令，来这里就对了。

第二层：simd —— 你的“os”

这一层，将是架构无关的、高级别的。它会定义一套通用的、不依赖特定向量宽度的向量类型（如 simd.Float32s），以及一套通用的操作（如 Add, Mul）。

当你写下 a.Add(b) 时，编译器会根据你当前的编译目标（GOARCH），自动将其翻译成最高效的底层 archsimd 指令。

这一层追求的是极致的可移植性和易用性。对于 99% 的开发者来说，你只需要和这一层打交道。

硬核拆解：Go 1.27 即将转正的 simd/archsimd

在 Go 1.26 的 GOEXPERIMENT=simd 实验成功后，Go 团队在 Issue #78979 中正式提案，将 simd/archsimd for AMD64 在 Go 1.27 中默认开启！

让我们来一睹这把“屠龙刀”的真容：

1. 强类型的向量定义

告别 unsafe.Pointer 和丑陋的字节数组！archsimd 为不同位宽和数据类型，定义了极其清晰的结构体：

// 128位，4个 uint32
type Uint32x4 struct { a0, a1, a2, a3 uint32 }
// 256位，8个 float32
type Float32x8 struct { /* ... */ }

2. 易于理解的方法链

所有的 SIMD 操作，都被设计成了易于阅读和链式调用的方法。注释里甚至贴心地标出了对应的汇编指令。

// Add each element of two vectors.
//
// Equivalent to x86 instruction VPADDD.
func (Uint32x4) Add(Uint32x4) Uint32x4

3. 抽象的掩码（Mask）类型

如何处理不同架构下千奇百怪的掩码，是 SIMD API 设计中最头疼的问题。Go 团队选择了用一个不透明的 Mask 类型来屏蔽底层差异，让编译器自己去选择最高效的实现（K-register 还是 Vector-register）。

Go的野心：可移植的 simd 包提案出炉

如果说 archsimd 只是让 Go “追平”了 C++/Rust，那么 Issue #78902 中提出的高级 simd 包，则真正展现了 Go 语言的“野心”——在可移植性上，超越所有前辈。

在这个提案中，dr2chase 描绘了一个极其诱人的未来。你将可以这样写代码：

// 一个 inner product 示例
func ip(x, y []float32) float32 {
    var a simd.Float32s // 注意！这里没有指定位宽！
    var i int
    // a.Len() 会在运行时自动返回当前 CPU 支持的最佳向量宽度
    for i = 0; i < len(x)-a.Len()+1; i += a.Len() {
        u := simd.LoadFloat32Slice(x[i : i+a.Len()])
        v := simd.LoadFloat32Slice(y[i : i+a.Len()])
        a = a.Add(u.Mul(v))
    }
    // ... 处理剩余的尾部数据
    return sum(a) // 水平求和
}

sum函数在amd64平台的具体实现：

//go:build amd64
package main
import (
    "simd"
    "simd/archsimd"
)

func sum(x simd.Float32s) float32 {
    switch a := x.ToArch().(type) {
    case archsimd.Float32x8:
        a = a.AddPairsGrouped(a)
        a = a.AddPairsGrouped(a)
        return a.GetLo().GetElem(0) + a.GetHi().GetElem(0)
    case archsimd.Float32x16:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    case archsimd.Float32x4:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    }
    panic("not a known type")
}

看懂了吗？

你只需要写一份代码，把它扔到一台只支持 AVX2 的机器上，a.Len() 会返回 8；把它扔到一台支持 AVX512 的机器上，a.Len() 会自动变成 16！

编译器会自动为你生成多个版本的代码，并在运行时动态选择最优路径。这彻底将开发者从“为不同 CPU 手写不同优化版本”的地狱中解放了出来。

神仙打架：一场关于“命名哲学”的激烈辩论

在 Issue #73787 的评论区，一场关于 SIMD 函数命名哲学的“神仙打架”，精彩绝伦。

以 Ian Lance Taylor 为首的“专家派”认为：

“应该直接使用 VPADDD 这样的汇编指令名。这对于专家来说更友好，他们不需要在脑子里多做一次‘Go 风格名称’到‘Intel 手册名称’的翻译。”
以 Cherry Mui 为首的“可读性派”则坚决反对：

“代码的读者，远比代码的作者多。一个普通开发者能轻易猜出 Add 的意思，但绝对猜不出 VPADDD 是什么鬼。我们应该为读者优化，而不是为专家。”

最终，“可读性派”胜出。这也再次印证了 Go 语言一以贯之的设计哲学：明确性与可读性，永远高于一切。

小结：Go 语言的“性能下半场”

SIMD 的正式入场，标志着 Go 语言的演进，正在进入一个全新的阶段。

如果说过去十年，Go 靠着“并发”和“简洁”赢得了云原生的上半场；那么在未来十年，它将靠着这套兼具“优雅可移植”与“极致性能”的 SIMD 工具链，去硬刚 AI、数据科学、游戏引擎这些性能深水区（如果后续新版本的 AI 学会了如何使用这些新增SIMD特性）。

Go 团队没有选择像 C++ 那样直接暴露几百个晦涩的 Intrinsics，也没有像 Rust 那样在稳定性和表达力之间反复纠结。

它用一套极其深思熟虑的“两层模型”，试图在这场性能的终局之战中，走出一条属于自己的路。

Go 1.27，将是我们所有 Gopher 重新认识这门语言的开始。

那扇通往极致性能的大门，正在被缓缓推开。你，准备好了吗？