BLblacksmythe·Nov 10, 2018
grpc-go: https://github.com/grpc/grpc-go
In Nine years of Gogrpc
grpc-go
Go2016–2026
grpc / grpc-go
grpc-go
The Go language implementation of gRPC. HTTP/2 based RPC
26Distinct people
28Mentions
0Explicit recommenders
23.1KGitHub stars
What to know before exploring
What it is
The Go language implementation of gRPC. HTTP/2 based RPC
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
- grpc/grpc · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 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 year28 dated mentions
Observed mentions: 2016-02-12 16:43:29 UTC to 2026-08-18 22:31:21 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 |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 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 | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 1 | 2 |
What Hacker News says
4 sourcesYou are claiming that is a one year old issue in the grpc-go project.
But we are not seeing any change in that code (https://github.com/grpc/grpc-go/blob/master/server.go#L228) in the following releases. And I tried to look for an issue mentionning MaxMsgSize and found nothing. https://github.com/grpc/grpc-go/issues?utf8=%E2%9C%93&q=MaxM...
The fix that would restore the compatibility you claim seems obvious:
func MaxMsgSize(m int) ServerOption {
return func(o *options) {
o.maxSendMessageSize = m
o.maxReceiveMessageSize = m
}
}
This fix could have been applied in a minor release to restore compatibility without breaking the API.
So if this is an issue, why is this not reported?
In Go vgo: Semantic Versioning and Human Errorvgo was explicitly designed to balance out two needs: (1) the need to use known good versions of the dependencies, and (2) the need not to burden dependency consumers with meaningless constraints (especially with an upper limit on the version). This article shows* why the first need is important, but it does not give vgo the credit for satisfying it with its minimal version selection (and, indeed, for providing a more stable and hence reliable solution than maximum version selection), and it misses the value of the second need. In my experience, the upper limit on the minor version is most often arbitrary, and in some cases when it is not, a future minor version reverts the mistakenly introduced incompatibility. Therefore vgo approach has unique advantages over other version selection methods, and it should not be discounted for the lack
Read the rest
of a feature necessary to provide them.
* The article says that "Prior to 1.4.0 there was one function of MaxMsgSize" which "had previously set the size on both send and receive" but it does not substantiate this claim, and it may be false since go-grpc 1.3.0 documents that "MaxMsgSize returns a ServerOption to set the max message size in bytes for inbound mesages" https://github.com/grpc/grpc-go/blob/v1.3.0/server.go#L166, and it has not changed in go-grpc 1.12.0 https://github.com/grpc/grpc-go/blob/v1.12.0/server.go#L228 which strongly suggests that this is not a bug.
That specific problem was resolved in July last year:
https://github.com/grpc/grpc-go/pull/1310
https://github.com/grpc/grpc-go/issues/1043
In Upcoming Go protobuf release