> timestamppb.New(time) is hard to figure out?
No need to be snarky; that API did not exist when I started using protobuf. The method was called `TimestampProto` which is not intuitive, especially given the poor documentation available. And it required error handling which is unergonomic. Given that they switched it to timestamppb.New, they must've agreed with me. https://github.com/golang/protobuf/blame/master/ptypes/times... <-- and you can still see the full code from this era on master because of the migration from `github.com/golang/protobuf` to `google.golang.org/protobuf`, which was a whole other exercise in terrible DX.
In Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)golang
protobuf
Go2014–2025
golang / protobuf
protobuf
Go support for Google's protocol buffers
24Distinct people
27Mentions
0Explicit recommenders
10.1KGitHub stars
What to know before exploring
What it is
Go support for Google's protocol buffers
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, 3:56:07 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 year27 dated mentions
Observed mentions: 2014-12-23 01:31:41 UTC to 2025-01-23 06:10:28 UTC.
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 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Go support for Protocol Buffers
This module
(github.com/golang/protobuf)
contains Go bindings for protocol buffers.
It has been superseded by the
google.golang.org/protobuf
module, which contains an updated and simplified API,
support for protobuf reflection, and many other improvements.
We recommend that new code use the google.golang.org/protobuf module.
Versions v1.4 and later of github.com/golang/protobuf are implemented
in terms of google.golang.org/protobuf.
Programs which use both modules must use at least version v1.4 of this one.
See the
developer guide for protocol buffers in Go
for a general guide for how to get started using protobufs in Go.
See
release note documentation
for more information about individual releases of this project.
See
documentation for the next major revision
for more information about the purpose, usage, and history of this project.
Package index
Summary of the packages provided by this module:
proto: Package
proto provides functions operating on protobuf messages such as cloning,
merging, and checking equality, as well as binary serialization and text
serialization.
jsonpb: Package
jsonpb serializes protobuf messages as JSON.
ptypes: Package
ptypes provides helper functionality for protobuf well-known types.
ptypes/any:
Package any is the generated package for google/protobuf/any.proto.
ptypes/empty:
Package empty is the generated package for google/protobuf/empty.proto.
ptypes/timestamp:
Package timestamp is the generated package for
google/protobuf/timestamp.proto.
ptypes/duration:
Package duration is the generated package for
google/protobuf/duration.proto.
ptypes/wrappers:
Package wrappers is the generated package for
google/protobuf/wrappers.proto.
ptypes/struct:
Package structpb is the generated package for
google/protobuf/struct.proto.
protoc-gen-go/descriptor:
Package descriptor is the generated package for
google/protobuf/descriptor.proto.
protoc-gen-go/plugin:
Package plugin is the generated package for
google/protobuf/compiler/plugin.proto.
protoc-gen-go:
The protoc-gen-go binary is a protoc plugin to generate a Go protocol
buffer package.
Reporting issues
The issue tracker for this project
is located here.
Please report any issues with a sufficient description of the bug or feature
request. Bug reports should ideally be accompanied by a minimal reproduction of
the issue. Irreproducible bugs are difficult to diagnose and fix (and likely to
be closed after some period of time). Bug reports must specify the version of
the
Go protocol buffer module
and also the version of the
protocol buffer toolchain
being used.
Contributing
This project is open-source and accepts contributions. See the
contribution guide
for more information.
Compatibility
This module and the generated code are expected to be stable over time. However,
we reserve the right to make breaking changes without notice for the following
reasons:
Security: A security issue in the specification or implementation may
come to light whose resolution requires breaking compatibility. We reserve
the right to address such issues.
Unspecified behavior: There are some aspects of the protocol buffer
specification that are undefined. Programs that depend on unspecified
behavior may break in future releases.
Specification changes: It may become necessary to address an
inconsistency, incompleteness, or change in the protocol buffer
specification, which may affect the behavior of existing programs. We
reserve the right to address such changes.
Bugs: If a package has a bug that violates correctness, a program
depending on the buggy behavior may break if the bug is fixed. We reserve
the right to fix such bugs.
Generated additions: We reserve the right to add new declarations to
generated Go packages of .proto files. This includes declared constants,
variables, functions, types, fields in structs, and methods on types. This
may break attempts at injecting additional code on top of what is generated
by protoc-gen-go. Such practice is not supported by this project.
Internal changes: We reserve the right to add, modify, and remove
internal code, which includes all unexported declarations, the
generator
package, and all packages under
internal.
Any breaking changes outside of these will be announced 6 months in advance to
protobuf@googlegroups.com.
Read the full README on GitHubWhat Hacker News says
27 sourcesI have no experience with Rust, but have been using Go professionally for ~5 years now. For a lot of the flak that Go gets (and praise that Rust gets), the Go standard library (and supporting ecosystem) indeed is fantastic for anything relating to a web server.
When I analyzed Rust around the same time, I noted the Rust standard library [1] did not have HTTP support, and it wasn't a first class consideration. I think Hyper [2] was around, but I've never analyzed it deeply (though based on GitHub stars it seems to be popular). Protobuf [3] is also extremely easy to work with in Go.
Given the differences in standard library and applications I see created in both ecosystems, your analysis seems right, though you can probably develop network(ed) applications in both fairly well at this point.
[0]: https://pkg.go.dev/std
[1]: https://doc.rust-
Read the rest
> It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.
People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'm all for that.
But ... 2 weeks ago I took over a half-finished Go project that's been left to "bitrot" for almost 3 years after the previous developer took a different job. Updating the Go dependencies was pretty easy; updating from 1.4.3 to 1.8.9 and such; maybe 1 or 2 with major version bumps, which were minor incompatibilities. Even the usage of the now-deprecated github.com/golang/protobuf wasn't a big deal, and updating
Read the rest
to use the new conventions was boring and unexciting, but fairly painless.
The frontend part ... yikes... Things need to be updated from 3.0.2 to 6.8.4 and nothing works if I update it. There are what seem like to be 500 releases in the meanwhile and a lot of changes to go through. It seems in those 3 years the entire world changed. I spent a day on this, and eventually resigned to just accepting the 100+ security vulnerabilities that npm install throws at me. Most, if not all, probably aren't a huge deal in a browser context, but still...
Certainly from my perspective, there seem to be some problems here. I just want to solve real-world problems and write code, not babysit my 1000+ dependencies for what is actually not a very complex project at all. Of course, you don't deal with any of this for new projects, but a 3 year jump really isn't that long of a period. Some churn is expected, but "yeah, maybe just throw a lot of it away and start from scratch"-kind of churn? Meh.
dsymonds strikes again..
David Symonds is a known type of bad actor within Google. Good luck if he latches onto your project or feature. This individual has consistently demonstrated a knack for deep sixing as much useful efforts as possible while simultaenously avoiding as much work as possible. The worst kind of BOFH developer I've encountered.
https://github.com/golang/protobuf/issues/156
It's just a sad aussie knoll troll situation.
In The Go language's first commit (1972)Maybe I'm missing something, but my read of golang/protobuf#364[1] was that part of the motivation for the re-organization in protobuf-go v2 was to allow for optimizations like gogoprotobuf to be developed without requiring a complete fork. I totally understand that the authors of gogoprotobuf do not have the time to re-architect their library to use these hooks, but best I can figure this generator does not use these hooks either. Instead it defines additional member functions, and wrappers that look for those specialized functions and fallback to the generic ones if not found.
For example, it looks like pooled decoders could be implemented by setting a custom unmarshaller through the ProtoMethods[2] API.
I wonder why not? Did the authors of the vtprotobuf extension not want to bite off that much work? Is the new API not sufficient
Read the rest
to do what they want (thus failing some of the goals expressed in golang/protobuf#364?
[1]: https://github.com/golang/protobuf/issues/364
[2]: https://pkg.go.dev/google.golang.org/protobuf@v1.26.0/reflec...
I'm one of the people responsible for the choice of versioning for the Go protobuf module. (Sorry!)
The original Go protobuf implementation is in the module "github.com/golang/protobuf".
A couple years back, we decided that it was time to do a major overhaul of the protobuf implementation. Protobufs were one of the first major pieces of Go code outside the standard library (the second post ever on the Go blog is about it), and there were a number of design decisions that made sense at the time but which we wanted to go back and revisit. Doing all of this was not going to be possible while preserving API compatibility.
Given that, we needed a new module path. That's the core of Go modules and API changes: You change the module path when you make an incompatible change. You can do this by bumping the major version of the module (since the m
Read the rest
odule path includes the version), or by changing the module path entirely. (There's another option, which I think doesn't get enough attention: You can just make the change, and force your users to deal with it. If you're okay with breaking your users when they upgrade, nothing stops you from doing this. We take backwards compatibility very seriously, so that wasn't an option for us.)
Given that we needed a new module path anyway, we took advantage of the opportunity to move to a path that isn't specific to a particular code hosting provider: "google.golang.org/protobuf". GitHub is great, we love GitHib, but we'd much rather have a provider-agnostic name for the module.
So we have a new module path. The question then was: What version do we tag the new module as when we release it? Remember that there has never been any version of "google.golang.org/protobuf" at this point; it's a completely new module.
One option was to tag it as v1.0.0. But that might be confusing, because this is "version 2" of the protobuf implementation, even if it's under a different module path. Also, if someone complains about a problem with "v1.2.0" and doesn't mention which module they're using, we won't have any way to tell which one they're talking about.
Another option was to tag it as v2.0.0. But that might be confusing, because there's never been a v1 of this package. Also, this would likely cause unnecessary confusion with "proto2" and "proto3" (versions of the protocol buffer language).
We waffled for quite a while, and eventually settled on v1.20.0, which avoids the missing v1 weirdness but also ensures that there is no overlap in versions between the two modules.
That confused people. Alas. Perhaps every option would have led to confusion.
In retrospect, perhaps we should have gone with v2.0.0 (and a module name of "google.golang.org/protobuf/v2"). Too late now; oh, well. If this was the worst decision we made in the new implementation (and so far, it looks like it may have been), I'll be quite happy.
I was referring to this:
https://blog.golang.org/protobuf-apiv2
> The github.com/golang/protobuf module is APIv1.
> The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider.
Basically, Google realized that it's not a good idea to tie your package's identity to
GitHub's URL scheme. This is easy for Google to fix, but the majority of Go packages suffer from the same problem, and it is much harder for a small project to start maintaining a DNS record that they control to point that to GitHub.
Not to mention, if GitHub decided to change its URL scheme for some reason, almost all Go builds on the planet would have to change.
And of course, the whole problem stems from relying on DNS to name your packages. No one wants to bothe
Read the rest
r with DNS, so they go for the low effort option and let some hosting provider handle it for them, without caring what happens in 10 years time.
> Some projects like GORM sidestep the issue entirely by tagging their 2.0 releases as far flung 1.x releases. That something of a solution, but smells terrible.
Amusingly, the Google protobuf team did a similar thing for the Go protobuf bindings. The new, backwards-incompatible `protobuf` module started with version 1.20, while the old module is at 1.4.
If you've followed this, you know I've omitted one detail - they actually changed the name of the module as well, from `github.com/golang/protobuf` to `google.golang.org/protobuf`. Because, of course, Golang modules names are actually URLs, not identifiers like in every other package manager out there.
In Go modules have a v2+ problemBecause the Go package name is github.com/golang/protobuf. Serving it from a different address is already a breaking change.
In A new Go API for Protocol BuffersThe original golang codegen omitted oneof support completely on the grounds that the concept didn't apply to golang.
Eventually they realized that oneof isnt an optional feature of proto - but the solution always felt rushed and bolted on because it was.
I hope the second try at proto api addresses these warts. I'm generally a golang fan - but not in this area.
Citations:
https://github.com/golang/protobuf/issues/29
In A new Go API for Protocol Buffers> - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.
> google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want.
I agree, this is confusing. Why doesn't google.golang.org/protobuf@v1 return what's at github.com/golang/protobuf, then, if only to provide a tidy answer for those who wonder what v1 looked like?
In A new Go API for Protocol BuffersTo quote one of the maintainers of the golang/protobuf implementation:
> The jsonpb package is intended to the be faithful implementation of the proto<->JSON specification, for which the C++ implementation is considered the canonical "reference" implementation.
And that C++ implementation does some kinda dumb things. For example, it marshals the protobuf type of int64 into a string when marshaling from a protobuf struct into JSON.
https://github.com/golang/protobuf/pull/916
I believe that the package they mention there is meant to be a more "canonical" protobuf <-> json marshaller than the existing jsonpb package.
In A new Go API for Protocol Buffers> The github.com/golang/protobuf module is APIv1.
> The google.golang.org/protobuf module is APIv2.
> We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider.
> (Why start at version v1.20.0? To provide clarity. We do not anticipate APIv1 to ever reach v1.20.0, so the version number alone should be enough to unambiguously differentiate between APIv1 and APIv2.)
Stuff like this is what makes Go confusing to newcomers.
For some time I couldn’t understand why people were complaining so much about —the now deprecated— GOPATH environment variable, and later the confusion of how to use all the different and incompatible dependency managers. Then, suddenly last year, it hits me… Go is confusing to people who haven’t followed the language from the beginning.
I started programm
Read the rest
ing in Go in 2013 so for me it was very easy to adapt to every change in the language and the community.
I can only imagine all the ambiguous stuff people have to understand when learning the language in 2019-2020.
Can you explain why it's not possible to create `google.golang.org/protobuf@v1` retroactively?
Also:
> In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone.
is the corollary that this change will cause 10 years of confusion?
In A new Go API for Protocol BuffersReasoning went something like this:
We could tag the new API v2:
+ Makes the "v1" and "v2" distinction very clear in the import path.
- Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.
- In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone.
We could tag the new API v1:
- Less visually distinct in the import path.
+ Seems to make sense for the first version of google.golang.org/protobuf to be a v1.
+ If we decide it was a terrible idea, it's easier to go from v1 to v2 than to roll back from v2 to v1.
We waffled back and forth for quite a while on this, and eventually decided that the first version of google.golang.org/protobuf would be a v1. Then as we got closer to release (but with a certain amount of usage of v0 in the wild), we decided not to second-guess that decis
Read the rest
ion but to start with a version that wouldn't overlap with any version of github.com/golang/protobuf to avoid confusion when someone reports a bug in "v1.0.1".
Maybe it was the wrong choice. If it was the worst choice we've made in the new API, I'll be happy!
Showing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.