Google has StatusOr<T> for this purpose: https://github.com/google/protobuf/blob/master/src/google/pr...
In When noexcept?protocolbuffers
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM 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
11 sourcesProtocol Buffers is not proprietary. It is open source under the BSD license. Here is the source code: github.com/google/protobuf. It is very much an open protocol, and anyone is free to write their own implementation of it. It is just a standards-based protocol.
If your organization values the existence of a standard over technical excellence, then there is no use in convincing you. Otherwise, in terms of ease of use, performance, tooling, and human readability and writability, Protocol Buffers is superior to XML-based protocols (since the API for converting between the binary and text formats is extremely simple to use).
As a fun fact, if you really wanted to use XML as a wire format, you could even write an XmlFormat ser/de for Protocol Buffers, similar to the JsonFormat that is already provided, but then it would defeat one of the mai
Read the rest
n purposes of using Protocol Buffers in the first place because you would replace an extremely performant wire format with an extremely sub-optimal one.
The question of how to reconcile leap-second-smearing systems with other systems is an interesting and important one. I'm not sure that timestamp.proto changes this issue: prior to timestamp.proto systems would still communicate using UNIX time (smeared or non-smeared) using plain integer or double seconds. timestamp.proto just provides a structure for storing UNIX time with greater range and precision than a single integer or floating point number can provide.
What I'm trying to say is that I think this is a smearing systems vs. non-smearing systems issue, and not so much a timestamp.proto issue. timestamp.proto mentions smearing but really it's just a vehicle for storing the seconds/nanos from the system clock, with whatever semantics that system clock uses. Because in practice systems don't give you access to both the smeared and n
Read the rest
on-smeared values; you get whatever the system gives you. The remarks about being leap-second-ignorant apply whether the leap second is being smeared or repeated.
Google implemented leap-second smearing in 2011, before the big push towards cloud. So the need to communicate sub-second timestamps between internal Google systems and external systems was probably not so much on people's minds. But these days we're releasing a bunch of APIs, and sub-second timestamps might become a more important issue for some of them.
So I think this issue is worth discussing further, and I opened an issue on GitHub to track it: https://github.com/google/protobuf/issues/1890
Thanks for the feedback.
No, I agree they did a bunch of good engineering for internal use.
But they didn't keep it internal properly -- the real world has leap seconds for better or for worse, and this library really does stick its head in the sand and pretend they don't exist. Google specifically says that this library is designed to be "the foundation of Google's new API platform". Yet they give a data type (as a headline feature) and a sample usage that is simply incorrect if you don't set your system to work using Google's "leap smear". It also seems quite likely that it'll result in blatantly wrong human-readable strings. I'll even quote a string from timestamp.proto [1]:
9999-12-31T23:59:59Z
That looks like an RFC 3339 string, and it even has the 'Z' suffix, which means it's UTC, which has an agreed-upon international definition. But this is not a val
Read the rest
id UTC time. It's a time in a different time zone that Google made up.
Google easily could have done better: publish a spec for a different kind of time like:
9999-12-31T23:59:59s
where the little 's' means 'smeared'. Supply a serializer and deserializer for that. Now there's no ambiguity.
[1] https://github.com/google/protobuf/blob/master/src/google/pr...
Protocol Buffers v3.0.0 released
278 points · Open discussion> An example of such an optimization is the arena allocator[1][2] employed by protobuf.
I work on the protobuf team at Google, so I'm aware of this.
Two things about that:
1. The underlying blocks for the arena allocator still come from the system allocator.
2. Because the arena allocator inhibits the capabilities of standard malloc-debugging tools like ASAN and Valgrind, the protobuf arena allocator includes special ASAN-aware code to mitigate this:
https://github.com/google/protobuf/blob/d64a2d9941c36a7bc2a7...
However, that code is ASAN-specific. It won't help other tools like Valgrind. So yes, different allocators are sometimes warranted for specific patterns like arenas. But if all you want is plain malloc()/free(), you should call malloc()/free().
If you're writing a library, letting the user specify their own allocation callback
Read the rest
is also great, since it lets the user do whatever custom bookkeeping/pooling/etc. they want to do. But by default just call malloc()/free() (IMHO).
Totally agree.
A few examples for me:
- From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?).
- At the top level of a repo (ie https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History".
- continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmark
Read the rest
s/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.
Because it doesn't deserialize protocol buffers, but protocol buffer descriptors. Descriptors are serialized protos of this type: https://github.com/google/protobuf/blob/master/src/google/pr... . Each descriptor is a parsed representation of a ".proto" file, including the message names and field names.
In Show HN: Pbd – Protocol Buffers Disassembler