https://github.com/protocolbuffers/protobuf/issues/1896
Ok some of the things I said couldn't be done, can be done, but it's situational
In Protobuffers Are Wrongprotocolbuffers
protobuf
C++2014–2026
protocolbuffers / protobuf
protobuf
Protocol Buffers - Google's data interchange format
89Distinct people
124Mentions
0Explicit recommenders
72.2KGitHub stars
What to know before exploring
What it is
Protocol Buffers - Google's data interchange format
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:53 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year124 dated mentions
Observed mentions: 2014-12-15 12:38:35 UTC to 2026-10-09 18:07:50 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 11 | 3 | 8 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 15 | 1 | 14 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 7 | 0 | 7 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Protocol Buffers - Google's data interchange format
Copyright 2008 Google LLC
Overview
Protocol Buffers (a.k.a., protobuf) are Google's language-neutral,
platform-neutral, extensible mechanism for serializing structured data. You
can learn more about it in protobuf's documentation.
This README file contains protobuf installation instructions. To install
protobuf, you need to install the protocol compiler (used to compile .proto
files) and the protobuf runtime for your chosen programming language.
Working With Protobuf Source Code
Most users will find working from
supported releases to be
the easiest path.
If you choose to work from the head revision of the main branch your build will
occasionally be broken by source-incompatible changes and insufficiently-tested
(and therefore broken) behavior.
If you are using C++ or otherwise need to build protobuf from source as a part
of your project, you should pin to a release commit on a release branch.
This is because even release branches can experience some instability in between
release commits.
Bazel with Bzlmod
Protobuf supports
Bzlmod with Bazel 8 +.
Users should specify a dependency on protobuf in their MODULE.bazel file as
follows.
bazel_dep(name = "protobuf", version = <VERSION>)
Users can optionally override the repo name, such as for compatibility with
WORKSPACE.
bazel_dep(name = "protobuf", version = <VERSION>, repo_name = "com_google_protobuf")
Bazel with WORKSPACE
Users can also add the following to their legacy
WORKSPACE file.
Note that with the release of 30.x there are a few more load statements to
properly set up rules_java and rules_python.
http_archive(
name = "com_google_protobuf",
strip_prefix = "protobuf-VERSION",
sha256 = ...,
url = ...,
)
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()
load("@rules_java//java:rules_java_deps.bzl", "rules_java_dependencies")
rules_java_dependencies()
load("@rules_java//java:repositories.bzl", "rules_java_toolchains")
rules_java_toolchains()
load("@rules_python//python:repositories.bzl", "py_repositories")
py_repositories()
Protobuf Compiler Installation
The protobuf compiler is written in C++. If you are using C++, please follow
the C++ Installation Instructions to install protoc along
with the C++ runtime.
For non-C++ users, the simplest way to install the protocol compiler is to
download a pre-built binary from our GitHub release page.
In the downloads section of each release, you can find pre-built binaries in
zip packages: protoc-$VERSION-$PLATFORM.zip. It contains the protoc binary
as well as a set of standard .proto files distributed along with protobuf.
If you are looking for an old version that is not available in the release
page, check out the Maven repository.
These pre-built binaries are only provided for released versions. If you want
to use the github main version at HEAD, or you need to modify protobuf code,
or you are using C++, it's recommended to build your own protoc binary from
source.
If you would like to build protoc binary from source, see the C++ Installation Instructions.
Protobuf Runtime Installation
Protobuf supports several different programming languages. For each programming
language, you can find instructions in the corresponding source directory about
how to install protobuf runtime for that specific language:
Language
Source
C++ (include C++ runtime and protoc)
src
Java
java
Python
python
Objective-C
objectivec
C#
csharp
Ruby
ruby
Go
protocolbuffers/protobuf-go
PHP
php
Dart
dart-lang/protobuf
JavaScript
protocolbuffers/protobuf-javascript
Quick Start
The best way to learn how to use protobuf is to follow the tutorials in our
developer guide.
If you want to learn from code examples, take a look at the examples in the
examples directory.
Documentation
The complete documentation is available at the Protocol Buffers doc site.
Support Policy
Read about our version support policy
to stay current on support timeframes for the language libraries.
Developer Community
To be alerted to upcoming changes in Protocol Buffers and connect with protobuf developers and users,
join the Google Group.
Read the full README on GitHubWhat Hacker News says
13 sourcesThis gets to the article's issue but from the dynamic typing angle as well.
By not allowing presence checks, one has to use convention _in every single class_ to determine basic things like PATCH semantics (https://github.com/protocolbuffers/protobuf/issues/359). This makes it impossible to treat protobuf as a general data format and requires object-specific logic to properly composite data structures. In some cases it's impossible to even do PATCH correctly without excluding sentinel values from the allowed range and having the application developer know about it.
There are so many other problems with Proto v3, but this one is glaring.
In Protobuffers Are Wrong> there is no proto2 library for C#!
Looks like that's getting fixed!
https://github.com/protocolbuffers/protobuf/blob/master/docs...
https://github.com/protocolbuffers/protobuf/pulls?q=is%3Apr+...
In Protobuffers Are WrongPython3 relative import syntax was flat out broken for years [0][1]. It's workable finally (not sure which PR fixed it) but it's still a monster to try to get protoc/grpc plugin to emit _pb2.py files which a) have correct import syntax b) have a top-level package name c) are readily packageable for pip install d) do all the above in a reproducible and uninstallable manner e) also be able to import 3rd party protos f) all the above without any post-processing.
Like, yes python constrains package names to the folder names. But why not check a flag so I can let the emitted python structure dominate the folder structure? Or, easier, just let me ignore the folder structure and specify a dang top-level-package in the emitted _pb2.py and let me wrangle it with setup.py?
[0] - https://github.com/protocolbuffers/protobuf/issues/90
[1] - https://gi
Read the rest
At this point I've written fairly little go code, but reviewed quite a bit. Among those I work with, my opinion seems to be shared.
> I think you'll find that visual structure is actually important.
I didn't say otherwise. What I did say is that go adds visual noise that isn't present in python. (and it is noise: the proposal to add try! shows that the error handling style is noisy. It can be basically entirely removed by an automated transformation). Actual pattern matching like rust has, or even what Google C++ has with StatusOr and [1] our nonsense RETURN_IF_ERROR macros are better than what go does, and just as explicit (actually often moreso, since its more difficult to forget an error condition)
[1]: https://github.com/protocolbuffers/protobuf/blob/d0f91c863ae...
In Python at Scale: Strict ModulesYou don't have to use exceptions in C++. Google doesn't, for example. Errors are reported with StatusOr<> like so:
https://github.com/protocolbuffers/protobuf/blob/master/src/...
In Linux kernel drivers in Rust might become an option in the futureSeems to be one of the best ways to go about it.
From the comment in protobuf source (which does the same thing as Python), mentioned in the Twitter thread:
(...) An arguably better strategy would be to use the algorithm described in "How to Print Floating-Point Numbers Accurately" by Steele & White, e.g. as implemented by David M. Gay's dtoa(). It turns out, however, that the following implementation is about as fast as DMG's code. Furthermore, DMG's code locks mutexes, which means it will not scale well on multi-core machines. DMG's code is slightly more accurate (in that it will never use more digits than necessary), but this is probably irrelevant for most users.
Rob Pike and Ken Thompson also have an implementation of dtoa() in third_party/fmt/fltfmt.cc. Their implementation is similar to this one in that it makes guesses and the
Read the rest
n uses strtod() to check them. (...)
https://github.com/protocolbuffers/protobuf/blob/ed4321d1cb3...
I wonder if Go just needs syntactic sugar that's similar to the RETURN_IF_ERROR that's common in Google C++ code (for example, in protobuf: https://github.com/protocolbuffers/protobuf/blob/master/src/...)
In An Open Letter to the Go Team About TryFor simple protocols protobuf decoding has no taken branches. I.e. if you only use the first 15 field numbers (all your tags are 1 byte) and if all the types are the expected types, and if all the variable-length items are < 128 bytes long then you can decode the message without taking any branches. In C++. Most of the other languages have simpler and slower codecs.
This is the hot path in C++[1]. A really large amount of work has gone into protobuf C++ performance in the last 3 years or so.
1: https://github.com/protocolbuffers/protobuf/blob/master/src/...
In Fast key-value stores: An idea whose time has come and goneIt looks like it’s basically a less hacky version of what the RETURN_IF_ERROR and ASSIGN_OR_RETURN macros[1] do in C++.
From experience, those work pretty well. That approach eliminates a lot of the boilerplate bookkeeping code, while still making it explicitly obvious to the reader that a given function call can fail.
This seems nice, and I would definitely use it.
[1] https://github.com/protocolbuffers/protobuf/blob/master/src/...
In Proposal: A built-in Go error check function, try`required` was removed due to the challenges it introduces in designing backwards-compatible API changes[1].
[1] https://github.com/protocolbuffers/protobuf/issues/2497#issu...
In Why We’re Switching to gRPCStatic type systems are just a tool. The type signature describes what _your_ module is capable of handling. If other modules pass incorrect data, your module will fail, whether statically or dynamically typed, albeit harder to debug in the dynamically typed case. If every field ends up being truly optional, it's going to be hard to change your module, because of the sheer weight of the combinatorial explosion of field subsets that may or maynot be set when third party modules interact with your module.
Most of the time optional fields:
* Encode that your module doesn't care about such-and-such fields, so the parser / type checker should just ignore them.
* Are used to encode variants of the same data that slightly changed in another module [id changed from number to string], so you should use an union type.
In practice, designing a stati
Read the rest
cally typed ecosystem for wire data is hard [0]. Grpc has basically gave up on validating field presence altogether [1]. These failures are directly caused by the immaturity of the ecosystem [deep decode batches of unrelated messages in middleware, WTF?]. It would be a mistake to throw the baby with the bathwater and blame the mathematically sound idea that your module can only process data of a certain shape, encoded by a suitable type signature.
[0] https://capnproto.org/faq.html#how-do-i-make-a-field-require...
[1] https://github.com/protocolbuffers/protobuf/issues/2497#issu...
All good points. It's worth mentioning that this is exactly why protobuf doesn't by default fail when it gets a field it doesn't recognize (there might be a flag to control strict validation, but there is a reason that "required" fields were taken out in proto3). From the source code:
https://github.com/protocolbuffers/protobuf/blob/master/src/...
// An UnknownFieldSet contains fields that were encountered while parsing a
// message but were not defined by its type. Keeping track of these can be
// useful, especially in that they may be written if the message is serialized
// again without being cleared in between. This means that software which
// simply receives messages and forwards them to other servers does not need
// to be updated every time a new field is added to the message definition.
A bit more detail:
For those who don't wo
Read the rest
rk with protos, they're the thing that Google created to use instead of XML before JSON was a thing. To use them, you define a message schema consisting of fields, where every field has (1) a number that will uniquely identify that field in the message, (2) a type for the field, and (3) a name for the field. The protoc compiler then generates code that decodes and encodes that specific message type for you.
Now think about what happens when a new field is added to that message type and the code is re-generated. That change is probably going to be in at least three different binaries (and it's often more): the client, the frontend, and the backend. There's no way to guarantee that every single client, frontend, and backend picks up that change at the same time - it has to go out incrementally. So if client v2 talks to frontend v1 and gets routed to backend v2, frontend v1 damn well better not crash if it sees a new field.