标签 Ruby 下的文章

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

本文永久链接 – 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 语言几乎是为这种“救火”场景量身定制的:

  1. 极致的性能与并发:Go 的性能远超 Ruby,其原生的 Goroutine 并发模型,能极其轻松地榨干现代多核服务器的性能,应对海量的网络请求。
  2. 极低的资源占用:相比于 Ruby 或 Python 这种动态语言,Go 的内存占用更小、更可控,能极大地降低服务器成本。
  3. 简单的部署:静态编译的单一二进制文件,使得将新的 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 来说是“生死存亡”的挑战,但对我们这些身处其中的技术人来说,又何尝不是一次“机遇”?

它告诉我们:

  1. 基础软件领域,永远有仗可打。 当所有人都涌向应用层,去卷 AI Agent 的花活时,那些能用 Go 或 Rust,去重构和加固底层基础设施的硬核工程师,其价值将变得空前稀缺。
  2. “稳定性”是最高的壁垒。 在一个功能可以被 AI 瞬间生成的时代,一个系统的长期价值,越来越多地体现在它的可用性、可靠性和可扩展性上。
  3. 保持警惕,准备“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}


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

硬核测评:哪门语言最受 AI 宠爱?13 种语言横向对比,Go 表现如何?

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

大家好,我是Tony Bai。

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

img{512x368}


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness 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