编程与软件工程reasonablypolymorphic.com
反对使用 Protobuf 的理由
Arguing against using protobuffers
2018 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章从编程语言理论的角度批评 Protocol Buffers 的设计，认为其类型系统、字段规则（如 optional/required/repeated）等选择在安全性、清晰度和语言集成方面做出了糟糕的权衡。文章在 2018、2019、2025 三次登上 HN 首页，引发了对 Protobuf 设计取舍的长期争论。
为什么经久不衰：它触及了 schema 设计与类型安全这一持续存在的问题，而 Protobuf 至今仍是 gRPC 生态的核心，这些批评与辩护在今天依然适用。
HN 评论精选
Protobuf 作者回应：设计是多方约束下的权衡，应先理解原因再批评
大家好，我是 Protocol Buffers 的实际作者之一 :) 我认为 Sandy 的分析应该先考虑 Protobuf 为什么会这样设计，而不是因为从编程语言中心的视角看不通就直接攻击这个设计。和所有软件系统一样，这是在众多相互竞争的约束下权衡妥协的结果。另外，我也不认为人身攻击是合理或有建设性的。—— D
dweis查看英文原文
Hi there, I'm an actual author of Protocol Buffers :) I think Sandy's analysis would benefit from considering why Protocol Buffers behave the way they do rather than outright attacking the design because it doesn't appear to make sense from a PL-centric perspective. As with all software systems, there are a number of competing constraints that have been weighed that have led to compromises. - D P.S. I also don't believe the personal attacks to be warranted or productive.
批评有理有据：Protobuf 为 Google 的规模牺牲了安全与易用，业界需要更好的统一 schema 方案
虽然我不喜欢夸张的语气和人身攻击，但作者并非全错。Protobuf 的许多设计选择明显与 Google 的规模和复杂度相关，牺牲了安全性、清晰度和语言集成。生成的代码极其别扭，尤其是 Go 生成器糟糕透顶——一旦涉及 oneof、时间戳或 well-known types，就没法把 Protobuf 结构体当作一等数据类型来写客户端或服务端。我们迫切需要一种更好的统一方式来表达 schema 并在网络上传递类型安全的数据；我现在的项目同时用 gRPC、GraphQL 和 JSON Schema，三者之间的重叠荒谬至极。难点在于没有两种语言是相同的，通用 schema 格式最终只能取最小公分母。
atombender查看英文原文
Though I dislike the hyperbolic tone and personal attacks, the author isn't entirely wrong. There are many design choices in Protocol Buffers that seem directly related to the scale and complexity at which Google operates, and which sacrifice safety, clarity and language integration. The utter awkwardness of Protobuf-generated code is particularly problematic. I've had pretty good results with the TypeScript code generator, but the Go generator is just egregiously bad. There's no way to write a client or server that uses the Protobuf structs directly as first-class data types without ending up looking like a ball of spaghetti, at least not if you venture into the realm of oneofs, timestamps or the "well known types" set of types. I think we're at a juncture where we really desperately need a better, unified way to express schemas and pass type-safe data over the network that flows through these schemas. I'm currently working on a project that involves both gRPC (which uses Protobuf), GraphQL and JSON Schema, with the backends written in Go, and the frontend in TypeScript, and the overlap between all of these is ridiculous. TypeScript is a fresh breath of air that mostly solves the brittleness of JavaScript's type system, and it's absolutely crucial to extend this type-safety all the way to the backend. The challenge is that no language is the same, and a common schema format ends up targeting a lowest-common denominator. For example, GraphQL errs (in my opinion, wrongly) on the side of simplicity and doesn't support maps, so now you have a whole layer that needs to either custom types (JSON as an escape hatch, basically) or emulate maps using arrays of pairs, neither of which is ideal.
前 Google 员工：这些设计来自大规模运维的实战经验，且 Google 对设计讨论持开放态度
我在 Google 待了 2.5 年，大部分工作就是把一个 protobuf 从一个地方推到另一个地方 :) 而且我很喜欢它。说实话，你可以抱怨一整天，但清单里那些决定很可能来自日常运维经验——支持各种压缩格式、protobuf 在不同数据库中的存储、代理转发等等。你列的 oneof 和 repeated 之类的选择，可能基于编码成本的度量数据。Google 过去（我相信现在也是）乐于讨论这些问题，你可以去设计文档上评论，真的能产生影响。我爱 protobuf，所以也许我有偏见……
malkia查看英文原文
I spent 2.5 years at Google, and most of what I did was pushing one protobuf from one place to another :) - and I loved it... Honestly though, you can complain all day, but some of the decisions made in the list you presented most likely come from experience (daily) not as a user of protobufs (which I simply was), but someone that had to support a plethora of compression formats, how protobufs gets stored in the different databases, proxying, etc. etc. Your "oneoff" and "repeated" might've been (I dunno really), a decision based on metrics where encoding repeated oneoff would've cost more, or made problems, more testing, or who knows what. For one, Google was, and I believe still is open to discussing all kinds of matters, and you can get on to a design doc and comment if you like, if you care, if you have something to say... You can definitely influence, and people really did talk (you can even experience this from their public design docs - like from chromium, etc.). And I love protobufs, so I guess I'm biased...
讽刺 map 字段不支持用户自定义类型参数化的设计缺陷
“尽管 map 字段可以参数化，但用户自定义类型不能。这意味着你得手写常见数据结构的特化版本。”真痛苦！好吧，至少 Google 不会再犯这个错误了！
twic查看英文原文
> Despite map fields being able to be parameterized, no user-defined types can be. This means you'll be stuck hand-rolling your own specializations of common data structures. What a pain! Well, at least Google won't make that mistake again!
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选