TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Protobuf Language Specification

194 点作者 akshayshah超过 2 年前

18 条评论

rigelbm超过 2 年前
Echoing some of the sentiment here: although this was certainly a great effort and the result is awesome, that is NOT The Protobuf Language Specification, for as long as the maintainers of the Protobuf (protoc) project don&#x27;t agree to follow it.<p>This is certainly The Buf Language Specification, which is useful in itself. Specs are like contracts. If I were to build a tool to be compatible with Buf, I would definitely aim it to work with this spec.<p>The problem is that the Protobuf project simply didn&#x27;t sign this contract. Whatever it says is, sorry for the choice of word, a bit pointless if I&#x27;m trying to build a tool compatible with Protobuf, specially around forward compatibility.<p>The industry does need better tooling around protobuf&#x2F;efficient RPC, and being dependent on a single company (i.e. Google) is definitely not healthy. I hope you guys succeed in what your are trying to doing.
评论 #32817375 未加载
评论 #32817655 未加载
评论 #32817444 未加载
kyrra超过 2 年前
Googler, opinions are my own. I don&#x27;t work on protobuf at all, just use it all the time (like most Googlers)<p>I haven&#x27;t dug into this in great detail yet, but the hard thing about the proto &quot;spec&quot; is that there isn&#x27;t one, and protoc lets you do all kinds of crazy things that are really hard to model in languages like Antlr. There were some poor choices in protoc dating back to when proto1 was first created that have been carried forward. Having 20 years of proto definitions lets people come up with some crazy use cases.<p>Definitely interesting for this company to create an EBNF definition for protobuf.
评论 #32816585 未加载
评论 #32816773 未加载
CobrastanJorji超过 2 年前
This is interesting. So one company invents and maintains a compiler, then a different company found that documentation to be insufficient (big surprise), so wrote out a lengthy standard that conformed to what the first company&#x27;s compiler happened to do? Seems very useful, but also seems risky and hard to maintain. What happens when Google tightens a constraint or adds a new feature next week?
评论 #32814931 未加载
评论 #32815291 未加载
评论 #32815224 未加载
评论 #32816884 未加载
评论 #32814796 未加载
jeffparsons超过 2 年前
&gt; As of today, Protobuf is now a fully-defined language:<p>(Etc.)<p>I&#x27;m not sure what this is meant to achieve in reality. There is still only one implementation that defines what the language actually is, and that is Google&#x27;s protoc.<p>I&#x27;m my experience working with and writing alternative parsers for the &#x27;.proto&#x27; language, I&#x27;ve found that time and again Google&#x27;s documentation for the format is either woefully vague, or directly contradicts the actual implementation. I don&#x27;t see the value in a third party &quot;spec&quot; if what I have to do in practice will always be &quot;whatever Google did in protoc&quot;.
评论 #32815019 未加载
评论 #32815633 未加载
评论 #32815034 未加载
habitue超过 2 年前
&gt; we are standing on the shoulders of giants, those who have built and battle-tested it, and brought it to its current mature state<p>I would rewrite this maybe to:<p>&gt; we are making Google&#x27;s internal problems into everyone&#x27;s problems<p>There are benefits to an IDL in the abstract, but an IDL for everyone should be built with the benefit of hindsight looking at the lessons of protobuf, ion, thrift, etc. Not just baking Google&#x27;s internal backwards compatibility obligations into a formal spec everyone should follow.<p>I think any time google takes an internal tool and flips the &quot;open source&quot; bit on it, it turns out to be a bad match for the rest of the world. When they instead take the time to build a new system that learns from the internal tool, like Kubernetes learned from Borg, I think the end result is significantly more valuable.
评论 #32817782 未加载
评论 #32818649 未加载
jvolkman超过 2 年前
This seems like a great resource. Kudos.<p>&gt; But most of them are based on the incomplete specs from Google&#x27;s developer site. None of them can correctly predict what source files protoc will actually accept or reject 100% of the time.<p>I&#x27;d like to think I got pretty close with the plugin that now ships with IntelliJ. It even supports the 65-bit integer literal [1] that protoc happens to accept for proto2-style float and double default values.<p>With this as a starting point, it&#x27;d be nice to fix some of the pecularities that arise from &quot;implementation as spec&quot;, such as that literal value, and the fact that colon optionality in text format is based on value type, not syntax.<p>1: <a href="https:&#x2F;&#x2F;github.com&#x2F;jvolkman&#x2F;intellij-protobuf-editor&#x2F;blob&#x2F;6e1f946ef24b19b97a777c7eb0f07d67dcbefb09&#x2F;core&#x2F;src&#x2F;main&#x2F;java&#x2F;idea&#x2F;plugin&#x2F;protoeditor&#x2F;lang&#x2F;psi&#x2F;ProtoNumberValue.java#L234-L243" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jvolkman&#x2F;intellij-protobuf-editor&#x2F;blob&#x2F;6e...</a>
评论 #32816222 未加载
jupp0r超过 2 年前
&gt; Protobuf is the most stable and widely adopted IDL today<p>I&#x27;ve run into this misconception so many times over the last decade. Protobuf is much less than an IDL (intentionally so). It&#x27;s used to describe the data of an interface but is completely unopinionated about all other aspects of an IDL. GRPC is a great example of how to use ProtoBuf in an IDL, but it could be used for other categories of interfaces (object oriented, etc). People treating ProtoBuf as an IDL make the mistake of concentrating too much on the data format and not about (imho) more important aspects like pre and postconditions etc, that make an interface an interface.
elcritch超过 2 年前
Lately I&#x27;ve been reading up on Amazon&#x27;s Ion format and think it&#x27;s underappreciated. It&#x27;s got a decent spec for both binary and text serialization formats, under an Apache-2.0 license even. Maybe I&#x27;m weird but I just don&#x27;t like using serialization formats that don&#x27;t include a specification for the binary format.<p>I also like where Ion goes with it&#x27;s symbol tables. They provide much of the space efficiency that Protobufs provide with schemas, but gives you much more freedom and flexibility. I&#x27;m a longtime fan of msgpack but it becomes inefficient if you transport field names with it. The Ion schema also seems nice as an alternative to Protobuf schemas, but able to describe arbitrary data constraints too.
mmastrac超过 2 年前
(removing my unfair characterization)
评论 #32814899 未加载
评论 #32815061 未加载
Cloudef超过 2 年前
Here is protobuf parser I wrote for a client w&#x2F; ragel&#x2F;c++. We needed way to parse the proto specification to generate our own code, since the google&#x27;s own C++ runtimes were way too huge for our use case especially with reflection. The nanopb in addition to the code generation w&#x2F; this parser was used in the end to keep the binary bloat in check.<p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;Cloudef&#x2F;7a69eba054f61ee63d6ee59262e1b695" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;Cloudef&#x2F;7a69eba054f61ee63d6ee59262e1...</a><p>I also did this benchmark for cap&#x27;n&#x27;proto, flatbuffers, protobuf and raw structs. This is already years old so it might not be accurate anymore, but what surprised me most was how different flatbuffers was compared to raw struct, as the design sounds like it should be merely extension to what is essentially raw struct + making sure the data can be portably encoded and decoded.<p><a href="https:&#x2F;&#x2F;cloudef.pw&#x2F;protobug.png" rel="nofollow">https:&#x2F;&#x2F;cloudef.pw&#x2F;protobug.png</a>
rad_gruchalski超过 2 年前
Question: if there’s no ebnf protobuf spec, what’s this then? <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;protocol-buffers&#x2F;docs&#x2F;reference&#x2F;proto3-spec" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;protocol-buffers&#x2F;docs&#x2F;referenc...</a><p>The text at the top of the page says:<p>&gt; This is a language specification reference for version 3 of the Protocol Buffers language (proto3). The syntax is specified using Extended Backus-Naur Form (EBNF) …
season2episode3超过 2 年前
It appears Google has released a spec as of 11 days ago: <a href="https:&#x2F;&#x2F;github.com&#x2F;protocolbuffers&#x2F;protobuf&#x2F;issues&#x2F;6188#issuecomment-1234641108" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;protocolbuffers&#x2F;protobuf&#x2F;issues&#x2F;6188#issu...</a>
评论 #32816905 未加载
advisedwang超过 2 年前
Is there a license on this spec?
评论 #32815809 未加载
peteradio超过 2 年前
Never having had the opportunity to put protobuf into action but having some interest I&#x27;ve had these questions:<p>1) What would you say is the best use case<p>2) and what unfortunate misusecases have you come across
评论 #32816551 未加载
评论 #32816426 未加载
评论 #32821111 未加载
IshKebab超过 2 年前
A good reference. I don&#x27;t think it was really needed in the same way that e.g. a JSON or C++ spec was, since the language is so simple there&#x27;s not much room for ambiguity. Definitely nice to have anyway.
评论 #32816198 未加载
elromulous超过 2 年前
Paging kentonv for his thoughts on this
评论 #32824165 未加载
cpurdy超过 2 年前
oh .. cool .. pricing for protobuf
silasdavis超过 2 年前
Golang is an example of a language defined by a spec not an implementation? Discuss.
评论 #32816916 未加载