Hacker News Reader

Comment by rigelbm | Hacker News Reader

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't agree to follow it.

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.

The problem is that the Protobuf project simply didn't sign this contract. Whatever it says is, sorry for the choice of word, a bit pointless if I'm trying to build a tool compatible with Protobuf, specially around forward compatibility.

The industry does need better tooling around protobuf/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.

View on HN

Actually, I thought about it twice and I retract what I said about this specification being pointless for building tools compatible with protobuf. Reasons:

* The language itself is unlikely to change much given it's been public for so long. A non-official spec that captures the current implementation is probably going to survive for some time.

* There's no official spec (which I would prefer) for me to base my tool on. This spec is about my only choice. The more tools targeting this spec, the hardest would be for Google to break compatibility with it, reinforcing my previous point.

I will keep the parent comment for context, and I don't retract the fact that I think the title is misleading. Otherwise, great work!!

Agreed. If IDEs and alternative compilers are all building off of the spec because it's the path of least resistance, and there are no bugs for a while, the defacto standard impl is going to face serious scrutiny for parting from it.

And, as you said, proto isn't in a great position to be making crazy changes anyway.

Our aim is to make the spec accurately match Google's reference compiler -- for as long as that is the source of truth, which is hopefully not forever :)

Even for those not using Buf, we expect this documentation to be of interest to the community as it describes a large number of facets of protoc that were previously undocumented (and required examining the source for protoc or playing around with test source code to see what it expects and what descriptors it generates).

If issues are found with this spec, it is true that we'll most likely have to revise the spec to match the compiler, not the other way around. But no software is perfect: some variations will be due to bugs in protoc, which can be fixed in the compiler to properly match the spec. Over time, we'd love to see an outcome where a formal specification is the source of truth.

For now, our commitment is to make (and keep) this spec as accurate as possible to describe the Protobuf language, not some Buf dialect.

That's basically the equivalent of RubySpec — reverse engineered from MRI (the original Ruby implementation) for use by Rubinius. It was adopted by the other alternative Ruby implementations too.

It looks like the original is now gone, but a fork has taken over. Looking at some comments, fighting to get MRI to adopt it may have burnt out the people behind it.

Reply on news.ycombinator.com