Protobuf 支持 LSP
Buf 为 Protobuf 新增的语言服务器协议（LSP）支持，正在引发人们对这种格式及其工具链的重新审视，尤其是与 JSON、REST 以及新兴的 LLM 驱动工作流相比。评论者讨论在概率模型盛行的世界里，像 Protobuf 这样的严格 schema 和 IDL 是变得不那么必要，还是更加关键，并提到性能、易用性、版本演进和多语言互操作性方面的权衡。这次发布还引发了关于 LSP 与 IDE 特定集成、Protobuf 以往编辑器支持，以及企业开源公告语气的讨论。
LLM 时代中 Protobuf 和 Schema 的角色
- 有人认为，LLM 会降低对重型 schema 工具、monorepo 以及以 protobuf 为中心的微服务基础设施的需求。
- 也有人强烈不同意，认为概率式代码生成使得严格、共享的契约 更加 重要。
- 分歧取决于未来系统是否把 LLM “in-band” 地用于行为，还是把它们当作辅助工具，最终仍交给确定性的、强类型的层来处理。
Protobuf vs JSON：性能与实用性
- 一派表示，对于一些 Google Cloud Python 客户端，gRPC/protobuf 比 JSON 更慢也更不可靠，并批评 protobuf 的复杂性、构建步骤和易用性。
- 另一派坚持认为，protobuf 通常在传输线上更快、更紧凑，而 JSON 的优势是可用性和无处不在，而不是性能。
- 还有人指出生态系统相关的注意事项：JS 中高度优化的 JSON 实现，以及 Python 中较弱的 protobuf 实现，可能会颠倒人们对性能的预期。
Schema、版本演进与测试
- 支持者看重 protobuf 的语言无关性、类型安全的数据交换能力，以及向后兼容的演进规则。
- 有人声称，如果你“理解 protobuf”，通常可以避免跨系统测试，因为 schema 演进行为是可预测的。
- 批评者认为，你仍然需要对业务逻辑进行校验和测试（例如字段之间的相互依赖），所以 protobuf 并不能消除真正导致故障的来源。
- 说明：只要字段编号和类型保持不变，重命名和重新排序字段在 wire 层面是兼容的；但重新编号，或将字段移入/移出
oneof，可能会有问题，尤其是在 JSON/text 格式或特定语言生成器中。
Buf 的 LSP 与解析方式
- Buf 的 LSP 作为
buf lsp serve子命令集成，建立在驱动 CLI 的同一解析器/编译器之上。 - 有人认为这是第一个规格完整、健壮的 protobuf LSP；早期方案则被批评为接受无效 proto 或缺乏完整校验。
- 关于 LSP 实现存在争论：复用“真正的”语言解析器，还是使用独立、具容错能力的解析器（tree-sitter 或自定义方案）。对于正确性和错误恢复是否能在单一解析器中共存，观点不一。
LSP、IDE 与开发者体验
- 有人说 protobuf 早已拥有不错的 IDE 支持（例如 IntelliJ 插件），因此质疑“第一个现代支持”的说法。
- 也有人认为，基于 LSP 的工具链更“现代”，因为它能与编辑器无关地集成，尽管深度 IDE 插件可能更强大。
- 少数人抱怨 LSP 会带来明显延迟；也有人认为这种延迟几乎可以忽略。
- 还有人猜测，随着基于 LLM 的编码工具发展，LSP/IDE 可能不再居于核心地位，但这一点仍有争议。
博客文章的语气
- 文章标题里原本的“You’re welcome”措辞被广泛认为傲慢或别扭；也有少数读者觉得外界的反弹有些过头。
- 公司后来承认了这个失误，修改了标题，并添加了编辑说明来解释意图和反馈。