标签 Golang 下的文章

Python简史:一个圣诞节的“私活”项目,如何改变了编程世界?

本文永久链接 – https://tonybai.com/2025/08/30/python-an-origin-story

大家好,我是Tony Bai。

在编程语言的星空中,很少有哪颗星像Python一样,以如此温和而坚定的姿态,从一个不起眼的个人项目,成长为照亮地球未来的科技灯塔。如今,当我们谈论数据科学、人工智能时,Python几乎是绕不开的默认选项。但这一切的起点,竟源于一位程序员在阿姆斯特丹的圣诞假期里,为了“打发时间”而开始的一个“私活”项目。

近期,一部名为《Python: The Documentary》的纪录片,通过对创始人Guido van Rossum及众多早期核心贡献者的访谈,为我们揭开了这段波澜壮阔的起源故事。这既是一部技术编年史,更是一部关于设计哲学、社区力量、时代机遇与人性光辉的启示录。

本文将沿着这部纪录片的脉络,和大家一起穿越回那个个人电脑尚不普及、Usenet是唯一交流渠道的年代,探寻和复盘Python成功的真正基因。

孕育:一次对“专家思维”的反叛

故事始于80年代的荷兰CWI(国家数学和计算机科学研究中心),一个诞生了Algol系列语言的学术圣地。当时,编程语言的设计理念被一种根深蒂固的经济关系所主导:计算机极其昂贵,而程序员相对廉价。因此,语言被设计得尽可能贴近硬件,以榨干机器的每一分性能,至于程序员需要花费多少时间去理解和编写,则在其次。

正是在这种背景下,CWI的ABC语言项目应运而生。项目成员Lambert Meertens在尝试向艺术家教授编程时发现,现有的语言充满了对底层硬件知识的隐式要求,这对非技术背景的人来说是一堵无法逾越的高墙。ABC的目标,就是创造一门“易学、易教、易用”的语言,让初学者无需关心“那些凌乱的硬件细节”。

Guido van Rossum,当时还是一名年轻的程序员,被雇佣来将ABC的原型实现为一个完整的系统。他在这门语言上投入了三年半的心血。然而,ABC生不逢时。在那个没有互联网的年代,分发软件需要邮寄软盘,ABC几乎没有触及到它的目标受众,并最终被CWI高层扼杀。

这次失败的经历,却在Guido心中埋下了一颗种子。

诞生:在C与Shell之间的“甜蜜点”

项目被砍后,Guido被调往一个名为Amoeba的分布式操作系统项目。他的任务是为这个系统编写大量的用户应用程序。他很快发现,使用C语言来完成这些任务极其痛苦和低效,而使用Shell脚本又缺乏足够的编程能力。

“天啊,如果我们能用ABC来写这些工具就好了,”Guido回忆道,“每个工具可能只需要半页代码,我几周就能搞定,而不是看起来要花上好几年。”

但他同样意识到,ABC过于抽象,它刻意回避了与文件系统、进程等操作系统底层交互的能力。此时,一个清晰的需求浮现了:市场需要一种能够弥合C语言的强大能力与Shell脚本的易用性之间鸿沟的语言。

当时,Perl是这个生态位的有力竞争者,但Guido和他的同事们并不欣赏它。“我们觉得它作为一门编程语言并不好,几乎和Basic一样糟糕,只是糟糕的方式不同。” 正是在这种“一个能打的都没有”的背景下,Guido做出了一个改变历史的决定。

1989年的圣诞假期,他没有选择休息,而是开始了自己的“私活”项目:创造一门属于自己的编程语言。

设计哲学:“禅”的雏形

Guido的新语言,自然地继承了ABC的许多思想遗产,其中最著名、也最具争议的,就是使用缩进来组织代码块。但他同样抛弃了ABC中那些他认为不切实际的部分,朝着更务实的方向前进。

更重要的是,Python从诞生之初就树立了一种与当时主流脚本语言Perl截然相反的哲学。Perl的座右铭是“条条大路通罗马”(There’s more than one way to do it),鼓励天马行空的语法和技巧。而Python则悄然确立了自己的核心原则:“应该有且最好只有一种显而易见的方法来做事”(There should be one– and preferably only one –obvious way to do it)。

这种对明确性(explicitness)可读性(readability)的极致追求,后来被社区核心成员Tim Peters总结为著名的《The Zen of Python》。当人们困惑于Python的设计哲学时,Tim Peters用诗一般的语言给出了答案:

  • Beautiful is better than ugly. (优美胜于丑陋)
  • Explicit is better than implicit. (明了胜于晦涩)
  • Simple is better than complex. (简洁胜于复杂)
  • Readability counts. (可读性很重要)

这可不是什么漂亮的口号,而是真正指导Python语言演进的根本大法。一位科学家用户在纪录片中分享道:“我用Perl处理数据,一年后回来看代码,完全不知道自己写了什么。而Python的代码,一年后我依然能读懂。” 这正是Python设计哲学的胜利。

社区的黎明:从Usenet的21个碎片开始

当Guido将这个名为“Python”(源自他喜爱的喜剧团体“Monty Python”)的语言展示给ABC的同事时,并非所有人都表示欢迎。他的导师Lambert Meertens的第一反应是输入一行代码,让解释器崩溃了,这让Guido备受打击。但第二天,他就修复了这个问题。这种务实、快速迭代的风格,贯穿了Python的整个发展历程。

很快,Python在CWI内部吸引了第一批真正的用户,Sjoerd Visscher和Jack Jansen。他们成为了Guido最初的反馈来源,“你只需要对他喊一声‘嘿,Guido!’”。一个微小的、紧密的社区开始形成。

历史的关键转折点在于CWI的开明决定:他们允许Guido以开源的形式将Python发布到全世界。“他们不知道这会成为一个巨大的成功,这很好,”Guido笑着说,“如果他们知道了,他们可能会阻止,那它就永远不会成功了。”

在那个前互联网时代,发布软件是一项艰苦卓绝的任务。团队必须将源代码打包、压缩、转换成ASCII编码,再分割成21个符合Usenet帖子大小限制的碎块。用户则需要手动下载所有碎片,再反向执行所有步骤。然而,Guido充满诱惑力的“预告”吸引了足够多的早期信徒,他们不辞辛劳地完成了这套复杂的“解压”流程。很快,来自世界各地的邮件和Usenet帖子开始涌入,一个全球性的社区就此诞生。

成长与迁徙:从NIST车间到成为“仁慈的独裁者”

Python的早期发展离不开美国国家标准与技术研究院(NIST)的一群爱好者。他们组织了第一次Python研讨会,只有20人参加,在一个“没有窗户的政府办公楼”里。正是这次会议,奠定了Python社区开放、协作的基调,也催生了Guido著名的头衔——“仁慈的独裁者”(Benevolent Dictator for Life, BDFL)

这个听起来有些戏谑的称号,精准地描述了Guido在社区中的角色:他欢迎所有人的想法,但保留对语言发展的最终决定权。这种模式在混乱的开源世界中提供了一种宝贵的稳定性和方向感,确保了Python在演进过程中没有因为无休止的争论而偏离其核心哲学。

随后,Guido移居美国,加入了CNRI(国家研究创新公司),这是他第一次可以全职投入到Python的开发中。在这里,他不仅获得了稳定的支持,还拥有了python.org域名,为社区建立了一个正式的家园。(一个有趣的插曲是,他们当时没有注册python.com,导致该域名多年来被一个成人网站占据。)

走向主流:科学计算与Web浪潮的双重助推

Python的崛起并非一帆风顺,而是踩中了数次技术浪潮的节拍。

  • 科学计算社区的拥抱:最初,科学家们使用Perl或MATLAB等工具,但Perl代码难以维护,而MATLAB是昂贵的商业软件。Python凭借其开源属性、出色的可读性和通过C扩展实现高性能计算的能力,迅速赢得了科学计算领域的青睐。NumPy、SciPy等库的出现,为Python构建了坚实的护城河。Guido本人虽然不是科学家,但他对社区需求的开放态度,使得Python能够不断演进,满足这个群体的需求。

  • 互联网泡沫与Web开发:2000年初,随着Web的兴起,开发者需要一种能够快速构建网络服务的语言。相比于Java的笨重和Perl的混乱,Python的“胶水语言”特性使其成为理想选择。Dropbox和YouTube等早期巨头的成功,雄辩地证明了Python在生产力上的巨大优势。Dropbox的创始人Drew Houston回忆道:“Google有一个百人C++团队在做视频网站,却始终追不上那个叫YouTube的小团队,后来他们发现,后者只有几个用Python的工程师。”

3.0之痛:一次差点撕裂社区的“大分裂”

当一门语言获得巨大成功后,如何处理历史包袱就成了一个棘手的问题。Python 2在Unicode和bytes处理上的混乱设计,成为了Guido心中的一根刺。2008年末,Python 3.0发布,这是一次不向后兼容的重大升级,旨在从根本上解决这些历史问题。

团队乐观地估计,社区只需要几年时间就能完成过渡。但他们严重低估了现实的阻力。对于拥有数百万行Python 2代码的公司(如Dropbox)来说,迁移成本是天文数字。许多核心库的维护者也迟迟不愿跟进,导致生态系统出现严重割裂。

这场“2 vs 3”的分裂持续了近十年,一度让社区陷入绝望。一些著名的开发者公开表示“不会迁移”,认为Python 3的收益不足以弥补其带来的痛苦。

最终,是时间、工具和榜样治愈了这场创伤。2to3、six等兼容库的出现降低了迁移门槛;Instagram等大型公司率先完成迁移并分享了性能提升的成功经验,给了社区巨大的信心;而Python 2.7在2020年正式停止支持,成为了压倒骆驼的最后一根稻草。

这场痛苦的经历给Guido和整个社区留下了深刻的教训:“Python可能已经太庞大了,再也无法承受一次这样的迁移。”如今,“永远不会有Python 4”已经成为社区的共识。

文化的胜利:Python的真正护城河

回顾Python的成功之路,语法和功能固然重要,但真正让它与众不同的,是其独特而强大的社区文化。

  • 开放与包容:从Guido亲自指导一位毫无开源经验的女性开发者Mariatta Wijaya成为核心贡献者,到PyLadies社区的兴起,Python社区在推动多元化和包容性方面做出了巨大努力。这使得Python不仅仅吸引了传统的白人男性程序员,还吸引了来自不同背景、不同领域的广大人群。
  • 幽默与人文关怀:从以“Monty Python”命名,到import this会打印出《The Zen of Python》,再到用“spam, spam, spam”作为会议T恤的口号,Python社区始终保持着一种轻松、幽默的氛围。这让参与开源不再是一件枯燥严肃的事情,而是一种有趣的社交活动。
  • “我为语言而来,为社区而留”: 这是前PyCon主席Jesse Noller的名言,也是无数Python开发者的心声。PyCon不只是一个技术会议,更像一个大型的家庭聚会。人们在这里交流思想,结交朋友,共同塑造着这门语言的未来。

小结:一场精心策划的“意外”

Python的成功,是一系列因素的完美风暴。它诞生于一个恰当的时机,满足了市场对一种更人性化、更高生产力语言的渴求。它的设计哲学——简洁、明确、可读——被证明是应对大型项目和团队协作复杂性的最佳解药。它抓住了一次又一次的技术浪潮,从科学计算到Web开发,再到今天的人工智能。

但最重要的,是Guido van Rossum和整个社区所展现出的务实、开放和人文精神。他们愿意为了长远的目标而承受短期的痛苦(Python 3迁移),也愿意为了让社区更美好而不断反思和改进。

这个始于圣诞节的“私活”项目,最终没有成为又一个被遗忘在历史尘埃中的ABC。它活了下来,并茁壮成长,因为它不仅是一门优秀的编程语言,更是一个充满活力的、不断进化的生命体。它的故事,至今仍在激励着每一个开源世界的参与者。


想系统学习Go,构建扎实的知识体系?

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


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

无聊的API是最好的API:从系统设计到接口契约的九条法则

本文永久链接 – https://tonybai.com/2025/08/29/good-api-design

大家好,我是Tony Bai。

在解读《Everything I know about good system design》一文时,我们曾提炼出一个核心观点:“无聊即可靠”。这个看似反直觉的法则,在追求创新与复杂的软件工程世界里,如同一股清流。现在,这个“无聊”哲学将从宏观的系统设计,延伸至微观但至关重要的领域——API设计。

Sean Goedecke在其后续力作《Everything I know about good API design》中,再次强调了这一理念。他认为,一个伟大的API,必然是“无聊”的。它不应追求新奇或有趣,而应像一把用了多年的锤子,让使用者拿起就能用,无需思考。

对于身处云原生和微服务浪潮之巅的Go开发者而言,API是我们日常呼吸的空气。本文将再次进入Goedecke的思想空间,学习他的API设计精髓,并将其提炼为九条具体的、可操作的法则。我们将探讨,如何通过拥抱“无聊”,在开发者熟悉性与系统灵活性之间找到完美平衡,构建出真正经得起时间考验的Go API。

法则一:追求无聊,API是工具而非产品

对于API的构建者,API是倾注心血的产品;但对于消费者(也就是开发者)而言,API纯粹是工具。他们在乎的是如何用最少的心智负担,最快地实现目标。任何让他们停下来思考“这个API为什么这么设计?”的时间,都是浪费。

一个伟大的API,必然是“无聊”的。 它的设计应该如此符合行业惯例和直觉,以至于开发者在阅读文档前就能猜到十之八九。

如果是在Go的世界里,这意味着:

  • RESTful: 遵循HTTP方法论。GET用于检索,POST用于创建,PUT/PATCH用于更新,DELETE用于删除。
  • 命名一致: 在JSON payload中全局统一使用snake_case或camelCase。
  • 结构可预测: 错误响应体遵循统一结构,如{“error”: {“code”: “invalid_argument”, “message”: “user_id cannot be empty”}}。

当你的API“无聊”到开发者可以几乎不假思索地使用时,你就为他们提供了最高效的工具。

法则二:视兼容性为生命,“绝不破坏用户空间”

Linus Torvalds的名言“我们绝不破坏用户空间”是API维护者的最高信条。API一旦发布,就如同一份公开签订的契约,你对所有下游消费者负有神圣的责任:避免伤害他们

破坏性变更(Breaking Change)是API的原罪,包括但不限于:

  • 删除或重命名字段
  • 修改字段类型 (int -> string)
  • 重构JSON结构 (user.address -> user.details.address)
  • 改变认证方式或核心业务流程

HTTP协议头中的Referer字段本应是Referrer,这个拼写错误之所以被永久保留,正是因为修正它会破坏无数现有系统。同样的,当年Unix系统API中open函数使用的oflag选项之一本应是O_CREATE,但实际上O_CREAT却一致沿用至今,也是为了保证API不被破坏的典型例子。为了API的所谓“整洁”或“正确性”而进行破坏性变更,是一种极其不负责任的行为。

Go的encoding/json库默认忽略JSON中未知的字段,这正是该原则的体现。它假定API会演进,从而保护消费者免受新增字段这类非破坏性变更的影响。

type User struct {
    ID   int    json:"id"
    Name string json:"name"
}
// 即使API返回 {"id": 1, "name": "Alice", "new_feature": true}
// 上述User结构体依然能成功解析,因为new_feature被优雅地忽略了。

法则三:版本控制是最后的“核武器”,而非常规升级工具

当破坏性变更的价值确实大到无法忽视时,唯一的负责任做法是版本控制(Versioning)。其核心是同时提供新旧版本的API,让用户按自己的节奏迁移。

在Go服务中,常见的两种版本实现策略如下:

  1. URL路径版本控制(最常见): /v1/users 和 /v2/users。在Go的chi或gorilla/mux路由器中实现非常直观。
  2. HTTP Header版本控制: 通过X-API-Version: 2 header指定。更灵活,但对客户端要求更高,可在Go中间件中实现。

然而,作者却尖锐地指出,版本控制是“必要的邪恶”。它会给用户带来文档查找的困惑,并让维护者的工作量和系统复杂性成倍增加。每个新版本都意味着一套全新的端点、测试用例和文档需要维护。即使后端通过“翻译层”共享核心逻辑,抽象泄漏也几乎不可避免。

因此,这条法则的真谛是:将版本控制视为你轻易不会动用的最后手段。你的首要目标应该是设计出无需版本更迭的、具有前瞻性的API。

法则四:产品价值优先,API的优雅是边际效益

一个残酷但必须接受的现实:API的成功99%取决于其背后产品的价值。用户使用API是为了与你的产品交互,而不是为了欣赏API本身的设计。

  • 产品为王: 如果你的产品(如Github、微信等)具有不可替代的价值,开发者会忍受其API的种种不便。对这些公司而言,投入巨资重构API的ROI远低于开发新功能。
  • 优雅无用: 如果你的产品无人问津,即使API设计得如艺术品般完美,也无人欣赏。

API质量是一个边际特性,它只在用户于两个功能几乎相同的竞品之间做选择时,才起到关键作用。但反过来说,是否提供API却是一个核心特性。一个没有API的产品在今天是不可想象的。

法则五:API是产品模型的镜子,先理顺内部逻辑

虽然好的API无法拯救一个坏产品,但一个糟糕的产品设计几乎必然会催生一个糟糕的API。API通常是产品核心资源(领域模型)的直接映射。如果你的内部模型本身就是一团乱麻,API这面镜子只会诚实地反映出这种混乱。

例如,一个系统的状态转换逻辑充满了各种隐式规则和特殊情况。反映在API上,可能就是你需要调用三个不同的端点,并传入一堆看似无关的参数,才能完成一个在UI上看起来很简单的操作。

在Go微服务架构中,这条法则尤为重要。在定义gRPC的.proto文件或RESTful的OpenAPI规范之前,请确保你的领域模型是清晰、一致且稳定的。否则,API将成为你技术债的永久性公开展示窗口。

法则六:认证必须简单,API Key是第一公民

你应该让用户能通过一个长期有效的API Key来使用你的API。

尽管OAuth2等短生命周期凭证更安全,但它们的复杂性对于初学者、脚本小子、甚至非专业工程师(如销售、产品经理)来说,是一个巨大的入门障碍。每一次成功的API集成,都始于一个简单的curl命令。API Key是让这个命令跑起来最快的方式。

# 这是任何开发者都希望看到的开始
curl -H "Authorization: Bearer YOUR_API_KEY" https://api.your-service.com/v1/users/me

在Go后端,处理Bearer Token是net/http中间件的一项基本功。先提供最简单的认证方式,再为有更高安全需求的企业级用户提供OAuth2等复杂选项,这才是明智的演进路径。

法则七:拥抱幂等性,让API调用无惧重试

当一个POST请求因为网络超时或服务器返回500而失败时,客户端将陷入两难:操作成功了吗?我应该重试吗?重试会造成重复创建吗?

解决方案是幂等性(Idempotency)。API应支持一个“幂等键”(Idempotency Key),通常通过HTTP Header(如Idempotency-Key: )传递。服务器在收到写操作请求时:
1. 检查这个幂等键是否在近期内处理过。
2. 如果处理过,直接返回之前保存的成功响应,而不执行任何操作。
3. 如果没有,则执行操作,并将幂等键与结果关联,存入一个短时效的存储中(如Redis)。

对于GET、PUT(全量更新)、DELETE这类天然幂等的操作,无需此机制。但对于POST(创建)和PATCH(部分更新),支持幂等性是API健壮性的重要标志。

在Go中,这可以优雅地作为一个中间件来实现,与核心业务逻辑解耦。

法则八:预设防线,用速率限制和熔断保护系统

UI用户的操作速度受限于人手,而API用户可以用代码发起洪水般的请求。任何暴露的API都可能被以代码的速度滥用,无论是恶意攻击还是无意的bug。

  • 实施速率限制(Rate Limiting):这是API的标配。使用如golang.org/x/time/rate等库,为每个用户或API Key设置合理的请求速率上限。
  • 返回限制信息:在HTTP响应头中包含X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After,让客户端能够智能地进行流量控制。
  • 准备“熔断器”:保留为特定用户或API Key临时禁用访问的能力,这是在系统遭受攻击或滥用时保护整体稳定性的最后防线。

法则九:面向未来,用游标分页处理大数据集

几乎所有API都需要提供列表查询功能。如果数据集可能增长到很大(例如,超过几千万条),简单的偏移量分页(?limit=20&offset=40)将成为性能灾难。

偏移量分页(Offset-based Pagination) 在数据库层面对应OFFSET … LIMIT …,当OFFSET值巨大时,数据库需要扫描并跳过大量记录,导致查询性能随页码增加而线性下降。

游标分页(Cursor-based Pagination) 是处理大规模数据集的最佳实践。客户端在请求下一页时,会传入上一页最后一条记录的唯一标识符(游标),如?limit=20&cursor=12345。SQL查询会变为WHERE id > 12345 ORDER BY id ASC LIMIT 20。由于id字段上有索引,这个查询无论翻到第几页,都能保持极高的、稳定的性能。

在你的Go API响应中,应该总是包含一个next_cursor字段,告诉客户端下一次请求应该使用什么值。

type UserListResponse struct {
    Data       []User json:"data"
    NextCursor string json:"next_cursor,omitempty"
}

法则:对于任何可能增长的数据集,都应默认使用基于游标的分页。 这是一种至关重要的前瞻性设计。

小结:API设计的“无聊”之道

这九条法则的核心,都指向了同一个目标:降低API消费者的认知负荷和未来风险。一个遵循这些法则的 API,在设计上可能是“无聊”的——它没有新奇的范式,没有炫技的结构。但正是这种“无聊”,才造就了它的可靠、可预测和易于集成。

在Go的世界里,我们拥有强大的工具来构建高性能的API。但最终决定一个API成败的,并非是选择了net/http还是gRPC,而是那些蕴含在设计细节中的同理心、远见和对“契约精神”的尊重。去拥抱“无聊”吧,这正是通往伟大API设计的智慧之路。


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

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

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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 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