标签 Golang 下的文章

dingo:Go 语言的 “TypeScript”时刻?—— 一场由社区驱动的语言演进实验

本文永久链接 – https://tonybai.com/2025/11/27/dingo-go-typescript-moment

大家好,我是Tony Bai。

Go 语言自诞生以来,以其极简主义哲学(Simplicity)赢得了全球开发者的青睐。然而,这种极简也伴随着长期的痛点:

  • 满屏的 if err != nil。
  • 缺失的和类型(Sum Types/Enums),导致状态表达含糊。
  • nil 指针带来的运行时 panic 风险。
  • 泛型虽已到来,但函数式编程体验(如 map/filter)依然匮乏。

在每年的 Go User Survey 中,这些问题总是名列前茅。

Gopher们渴望“越狱”,但Go 核心团队对此保持审慎,这不仅是为了保持语言的纯粹,也是为了向后兼容。

一个名为dingo 的开源项目的出现,试图打破这一僵局。它自称是 “逃逸的 Go”(Go that escaped)。就像 TypeScript 之于 JavaScript,dingo 试图在不改变 Go 运行时、不引入额外依赖的前提下,通过编译时转译,为 Gopher 们提供现代化的语法糖和类型安全。

在本文中,我们就来深入剖析 dingo 的核心机制与创新语法,看看它是如何在保持 Go 零运行时开销的同时,实现那些 Gopher 们梦寐以求的现代语言特性的。

dingo 是什么?

简单来说,dingo 是一门元语言(Meta-language)。它拥有类似 Rust 或 TypeScript 的现代语法,但最终会被编译成纯粹的、符合惯例的 Go 代码

其核心价值主张包括:

  1. 零运行时开销:编译产物就是标准的 Go 代码,性能与原生 Go 完全一致。
  2. 向后兼容:可以直接引入现有的 Go 包,生成的代码也可以被其他 Go 项目引用。
  3. 类型安全增强:引入 Option 和 Result 类型,语法层面消灭空指针异常。
  4. 人体工程学升级:通过?操作符和模式匹配(Pattern matching),大幅减少样板代码。

注:为什么叫 dingo(澳洲野犬)?dingo项目的README 中有一个有趣的隐喻:Go 的吉祥物 Gopher(地鼠)是规矩的、被管理的;而 dingo(澳洲野犬)曾是家犬,后来逃入荒野,恢复了野性。dingo 语言依然保留了 Go 的基因,但它拒绝被传统的规则束缚——它代表了未经许可的自由


核心特性与代码对比

dingo 并非为了标新立异,而是为了解决实际问题。以下是它如何通过转译解决 Go 的四大痛点:

错误传播:告别 if err != nil

Go 的错误处理不仅啰嗦,而且容易打断阅读逻辑。dingo 引入了类似 Rust 的 ? 操作符。

dingo 写法:

// 看起来像 Rust,实际上是 Go 的超集
func processOrder(orderID: string) -> Result<Order, Error> {
    let order = fetchOrder(orderID)?          // 如果出错,直接返回 Err
    let validated = validateOrder(order)?     // 自动解包 Ok 的值
    let payment = processPayment(validated)?
    return Ok(payment)
}

转译后的 Go 代码(自动生成):

func processOrder(orderID string) (Order, error) {
    order, err := fetchOrder(orderID)
    if err != nil {
        return Order{}, err
    }

    validated, err := validateOrder(order)
    if err != nil {
        return Order{}, err
    }
    // ...以此类推
}

我们从上面示例代码的字面上就能看到收益:样板代码减少约 67%,业务逻辑一目了然。

Sum类型与模式匹配

这是 Go 社区呼声最高的功能之一([Proposal #19412](在本文中,我们就来深入剖析 Dingo 的核心机制与创新语法,看看它如何在保持 Go 零运行时开销的同时,实现那些 Gopher 们梦寐以求的现代语言特性。))。dingo 通过 enum 和 match 完美实现了这一点。

dingo 写法:

enum Shape {
    Circle { radius: float64 },
    Rectangle { width: float64, height: float64 },
    Point,
}

func area(s: Shape) -> float64 {
    match s {
        Circle(r) => 3.14 * r * r,
        Rectangle(w, h) => w * h,
        Point => 0.0
    }
}

dingo 将 enum 转译为 Go 的 struct + tag(标签联合体),并生成辅助方法(如 IsCircle(), NewCircle())。match 语句在编译时会进行穷尽性检查(Exhaustiveness Checking),如果你漏掉了一种情况,编译就会报错。

3. 空值安全

受 Swift 和 Kotlin 启发,dingo 引入了安全导航(Safe navigation)操作符 ?. 和空值合并操作符 ??。

dingo 写法:

// 还在写嵌套的 nil 检查吗?
let city = user?.address?.city?.name ?? "Unknown"

转译后的 Go 代码:

这会被展开为一系列的 if 检查或立即执行函数表达式,确保不会发生 panic。

4. 函数式编程工具

dingo 写法:

let numbers = []int{1, 2, 3, 4, 5}
let doubled = numbers.filter(|x| x % 2 == 0).map(|x| x * 2)

支持 TypeScript 风格的箭头函数 (=>) 或 Rust 风格的管道符 (||)。


技术架构与实现原理

dingo 的实现非常务实,它没有重写整个 Go 编译器,而是采用了两阶段转译架构

编译器架构

  • Stage 1: 预处理器 (Preprocessor)
    • 处理 dingo 特有的语法糖(如 ? 操作符、enum 定义、类型注解 : Type)。
    • 使用基于正则和文本的转换,将 dingo 代码转换为“合法的”但包含特殊标记的 Go 代码。
  • Stage 2: AST 转换 (Plugin System)
    • 利用 Go 原生的 go/parser 解析代码。
    • 通过插件系统(Plugins)对 AST(抽象语法树)进行语义层面的转换。例如,将 Result 展开为具体的 struct 定义。
  • Code Generation: 最后使用 go/printer 输出格式化好的 Go 代码。

IDE 支持的秘密武器:Source Maps

许多转译语言失败的原因是调试体验差——报错指向生成的代码,而不是源码。

dingo 实现了精确的 Source Maps (v1 格式)

  • 它建立 .dingo 文件和生成 .go 文件之间的双向映射。
  • LSP 集成:dingo 开发了一个 LSP 代理(Proxy),它包装了官方的 gopls。当你请求“跳转定义”时,代理拦截请求,利用 Source Map 将位置从 dingo 坐标转换到 Go 坐标,发送给 gopls,拿到结果后再转换回来。这样,你在 VS Code 中写 dingo,享受的是 Go 级别的智能提示和重构能力。

混合包管理策略

dingo 采用了一种聪明的混合策略来解决生态兼容性:

  • 应用开发:保留 .dingo 文件,忽略生成的 .go 文件。开发体验类似 TypeScript。
  • 库开发:在发布时,将 .dingo 转译为 .go 并提交到版本控制系统。
  • 意义:任何纯 Go 项目都可以 go get 一个用 dingo 写的库,而不需要安装 dingo。这是生态融合的关键。

哲学与争议:为什么这很重要?

dingo 的 项目说明文档中提出了一个深刻的观点:“自私地使用 dingo,顺便推动 Go 的演进。”

TypeScript 最初并非为了改变 JavaScript 标准,而是为了让开发者在大项目中活下来。但随着 TS 的普及(Async/Await, Optional Chaining),这些特性最终被吸纳进 ECMAScript 标准。

dingo的对 Go 核心团队的参考价值,和TS类似。

Go 核心团队在引入新特性时非常依赖“证据”而非“理论”。 Proposal #19412 尚未被accept,是因为缺乏 Go 语境下的具体实现范例。但 dingo 如果能拥有 5 万开发者,它就提供了一份实证数据

  • “使用了 ? 操作符的项目,代码量减少了 X%。”
  • “和类型在 Go 的 runtime 上运行良好,并没有导致性能下降。”

因此,dingo 不是 Go 的竞争者,它是 Go 未来的沙盒。


上手指南与现状

目前,截至本文编写时, dingo 还处于 v0.3.0-alpha 阶段,主要核心特性(Sum类型、模式匹配、错误传播、LSP 支持)完成度还不高,仅适合向往拥有Rust、TypeScript等表达力更强的语法的Gopher尝鲜体验之用。

快速安装

# 克隆仓库并构建编译器
git clone https://github.com/MadAppGang/dingo.git 或 git clone --depth=1 git@github.com:MadAppGang/dingo.git
cd dingo && go build -o dingo ./cmd/dingo

# 将 dingo 加入环境变量 (可选)
export PATH=$PATH:$(pwd)

验证安装结果:

# dingo version

Hello World

# 编写 hello.dingo

package main
func main() {
    let msg = "Hello from dingo"
    println(msg)
}

# 编译并运行(dingo 会自动调用 Go 编译器)
dingo run hello.dingo

运行过程中,dingo会生成转义后的hello.go代码:

package main

func main() {
        msg := "Hello from dingo"
        println(msg)
}

大家通过转义后的代码,也可以看到它的转换过程和原理。


小结

dingo 是一个大胆的实验。它证明了我们可以在不分叉 Go 语言、不分裂生态系统的前提下,拥有现代化的语言特性。

不过,目前dingo的完成度还非常低,很多项目自带的example都build/run failed,这也是本篇文章可以运行的示例较少的原因:(。根据作者的Roadmap,目前很多新增的语法特性还处于未完成阶段。

但对于 Gopher 来说,如果你厌倦了 if err != nil,将来一旦完成度上来的dingo 很值得一试。即使你坚持使用纯 Go,dingo 的存在也是一件好事——它是一只被放入沙丁鱼群的鲶鱼,或许能激活 Go 语言演进的一池春水。

正如dingo项目宣言所说:这是你的语言,你的规则。无需委员会批准。


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

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

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


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

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

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

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

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


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

13万节点!Google 如何打破 Kubernetes 的物理极限,构建全球最大集群

本文永久链接 – https://tonybai.com/2025/11/26/how-google-built-a-130000-node-k8s-cluster

大家好,我是Tony Bai。

Kubernetes 的官方支持上限通常被认为是 5,000 到 15,000 节点。然而,在 AI 时代的算力军备竞赛中,这个数字显得有些“捉襟见肘”。

近日,Google Cloud 发布了一份重磅技术报告,揭示了他们如何在 GKE (Google Kubernetes Engine) 上成功运行了一个130,000 节点的超大规模集群——这是目前已知全球最大的 Kubernetes 集群,其规模是 GKE 官方支持上限(65,000 节点)的两倍,更是开源 Kubernetes 社区上限的近十倍。

这不是一次规模的堆砌,而是一次涉及控制平面、调度器、存储和网络的系统级工程实践,极具参考价值。Google 是如何做到的?让我们深入其架构内部,一探究竟。

背景:AI 时代的“巨兽”需求

推动这一极限挑战的核心动力,是日益庞大的 AI 工作负载。随着大模型训练对算力需求的指数级增长,客户不再满足于万卡集群,而是向着 10万节点 的规模进军。

在这个量级下,挑战不仅来自芯片的短缺,更来自电力和数据中心的物理限制。一个拥有数万块高性能 GPU 的集群,其功耗可能高达数百兆瓦,必须跨越多个数据中心部署。这要求 Kubernetes 不仅要管理庞大的资源,还要具备跨故障域、跨数据中心的极致编排能力。

核心创新:四大技术支柱

为了支撑起这座“13万节点”的摩天大楼,Google 对 Kubernetes 的底层架构进行了四项关键的“手术”。

1. 读操作的极致优化:一致性缓存

在 13 万节点的集群中,数以百万计的 Pod 和对象会产生海量的 API 请求。如果所有读请求都直接打到 etcd(或 GKE 使用的 Spanner),数据库瞬间就会被压垮。

Google 的解决方案是:让 API Server 直接从内存缓存中服务读请求,同时保证强一致性。

具体来说,就是通过引入 Consistent Reads from Cache (KEP-2340),API Server 可以利用其内存中的 Watch Cache 来服务 GET 和 LIST 请求。

系统会确保缓存中的数据在服务请求前是可验证的最新状态(verifiably up-to-date),从而在不牺牲一致性的前提下,大幅降低了底层数据库的压力。

同时,通过 Snapshottable API Server Cache (KEP-4988),API Server 甚至可以直接从内存中构建 B-tree 快照,来服务带有 resourceVersion 的历史数据查询,彻底消除了“读放大”问题。

2. 存储后端的无限扩展:基于 Spanner 的分布式键值存储

标准的 Kubernetes 使用 etcd 作为存储后端,但在 13 万节点的规模下,etcd 的容量和吞吐量成为了瓶颈。

GKE 替换了这一层,使用了一个基于 Google Spanner 的专有键值存储系统。

  • 性能数据:在测试中,该存储系统轻松支撑了 13,000 QPS 的租约 (Lease) 更新操作,确保了 13 万个节点的健康检查心跳畅通无阻。
  • 容量:在峰值时,数据库中存储了超过 100 万个 Kubernetes 对象,依然保持了极低的延迟和极高的稳定性。

3. 调度器的进化:Kueue 与工作负载感知

默认的 Kubernetes 调度器是“Pod 中心”的,它一个个地调度 Pod。但这对于 AI 训练任务来说远远不够——AI 任务通常需要“全有或全无” (All-or-Nothing) 的调度保证(即 Gang Scheduling)。

Google 引入了 Kueue,一个构建在原生调度器之上的作业级 (Job-level) 队列管理器。Kueue 负责决定何时接纳一个作业,基于配额、优先级和公平策略进行裁决。它实现了Gang Scheduling,确保一个训练任务的所有 Pod 要么全部启动,要么全部排队,避免了资源死锁。

4. 数据访问的加速:GCS FUSE 与本地化缓存

对于 AI 训练,数据加载速度至关重要。GKE 利用 Cloud Storage FUSE 配合并行下载和区域性缓存 (Anywhere Cache),让存储在 GCS 对象存储中的海量数据,能像本地文件系统一样被 Pod 高速访问。这使得数据加载延迟降低了 70%,确保了 GPU 不会因为等待数据而空转。

实战演练:一场 13 万节点的压力测试

为了验证这套架构,Google 设计了一个包含四个阶段的极限压力测试,模拟了真实的 AI 生产环境。下图展示了整个测试的时间线和四个关键阶段。


图注:13万节点压力测试的完整执行时间线

阶段一:基线测试 —— 1000 Pods/秒的狂飙

在一个空集群中,一次性启动 130,000 个 Pod 的大规模训练任务。结果显示,控制平面极其稳定,支撑了高达 1,000 Pods/秒 的创建和调度吞吐量。


图注:控制平面的吞吐量监控

阶段二:混合负载与争抢 —— Kueue 的“铁腕”

测试引入了大量低优先级的批处理作业填满集群,然后突然提交高优先级的微调任务。此时,Kueue 展现了惊人的动态调整能力:它在 93 秒内精准抢占了 39,000 个低优 Pod,瞬间腾出资源给高优任务。


图注:Kueue 正在进行资源调度

阶段三与四:突发流量与弹性恢复

在第三阶段,模拟了“双十一”式的流量洪峰,提交最高优先级的推理服务。系统再次平稳应对,甚至在极高负载下,推理 Pod 的 P99 启动延迟仍控制在 10 秒左右,这对于对延迟敏感的在线服务至关重要。


图注:不同负载类型下的 Pod 启动延迟

最后,当流量退去,系统自动释放资源,重新接纳之前被挂起的低优任务,实现了资源的完美闭环和极致利用。

小结:这就是未来的基础设施

Google 的这次 13 万节点实验,不仅是秀肌肉,更是为整个云原生社区指明了方向。它证明了 Kubernetes 在经过合理的架构优化后,完全有能力承载 AI 时代最苛刻的算力需求。

内存一致性缓存工作负载感知的调度,这些在极限场景下打磨出的技术创新,最终都会反哺到普通的 GKE 集群,甚至回馈给开源社区(如 Kueue 和 KEP 提案)。

对于我们每一位架构师而言,这都是生动的一课:真正的可扩展性,不仅仅是堆砌硬件,更是对系统每一个环节——从读写路径到调度逻辑——进行极致的工程优化。

资料链接:https://cloud.google.com/blog/products/containers-kubernetes/how-we-built-a-130000-node-gke-cluster/

聊聊你对“规模极限”的看法

Google的13万节点集群,为我们展示了云原生技术栈在AI时代的巨大潜力。在你看来,Kubernetes或其他云原生技术的下一个“物理极限”会是什么?除了Google提到的这四项优化,你认为还有哪些关键技术能帮助我们突破规模的瓶颈?或者,你在自己的工作中,遇到过哪些有趣的“规模化”挑战和解决方案?

欢迎在评论区留下你的真知灼见,让我们一起探讨未来基础设施的模样!

如果这篇文章让你对大规模系统设计有了新的启发,别忘了点个【赞】和【在看】,并分享给更多对技术极限充满好奇的同伴!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

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

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


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

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

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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats