Comment by inetknght

> gRPC is widely deployed at many companies that do offer bug bounties

Ahh yeah, bug bounties. The things that are notoriously underpaid if paid at all. The things that require many hours/days/weeks of work for a "maybe" payoff.

I'm sorry but I don't like the risk of spending so much time for free or significantly discounted. My time is worth more than that.

If these companies really want to lean on shit software, then that's their business. But I neither support nor condone it.

> gRPC library does not even have a dependency on `libprotobuf`

I see this espoused a lot. Have you tried building gRPC? It requires protobuf to build...

> You just went from the claim "they have no fuzzers or static analysis" to "fuzzers don't cover X"

And it's amazing that both claims are true. You linked some page where some fuzzers were run. Nice! Those fuzzers aren't enabled in default tests. So `make test` doesn't run them. Moreover `make test` didn't find any issues and would take a while so I commented it out.

> I would be really interested to see a comparable RPC stack

This has been a call since forever. But "RPC" is very loosely defined.

Realistically, almost anything that can serialize to/from a file without relying on knowing the file size can be adapted to socket-based RPC. There's thousands of libraries which can do that.

> that is close or more well-tested than gRPC

I'd rather have an "RPC" whose design is both well-documented and clearly readable. That's definitely not gRPC. HTTP is fairly well-documented and many implementations are clearly readable. Message queues are too. Even databases are generally better documented and usable for RPC. Did you know that POSIX has a specification for RPC?

Good documentation and clearly readable means "well tested" comes with much lower costs.