Hacker News new | ask | show | jobs
by neonsunset 725 days ago
It is possible to do quite well, as demonstrated by .NET.

Edit: and, if I remember correctly, gRPC tooling for it is maintained by about 1-3 people that are also responsible for other projects, like System.Text.Json. You don't need numbers to make something that is nice to use, quite often, it makes it more difficult even.

4 comments

For the longest time (up until earlier this year[0]), you couldn't even get the proto details from a gRPC error. IME GP is correct, there are so many caveats to gRPC implementations that unless it is a prioritized, canonical implementation it will be missing things. It seems there are tons of gRPC libraries out there that fell behind or were missing features that you don't know until you need them (e.g. I recently had to do a big lift to implement HTTP proxy support in Tonic for a project).

0 - https://github.com/grpc/grpc-dotnet/issues/303

> unless it is a prioritized, canonical implementation it will be missing things

Perhaps. But for now, such canonical implementation (I assume you are referring to the Go one?) is painful to access and has all around really bad user experience. I'm simply pointing out that more ecosystems could learn from .NET's example (or just adopt it) rather than continuing to exist in their own bubble, and more engineers could have zero tolerance to the tooling with bad UX as it becomes more popular.

Now, with that said, I do not think gRPC is ultimately good, but I do think it's less bad than many other "language-agnostic" options - I've been burned badly enough by Avro, thanks. And, at least within .NET, accessing gRPC is even easier than OpenAPI-generated clients. If you care about overhead, Protobuf will always be worse than bespoke solutions like RKYV or MemoryPack.

I'm looking forward to solutions inspired by gRPC yet made specifically on top of HTTP/3's WebTransport, but that is something that is yet to come.

No disrespect to the other developers on the team, but James Newton-King is no ordinary developer.
.NET looks quite good, as well as Swift actually. I have most experience with Java, and those are almost as nice as the .NET bindings. I have also used Go quite a bit, and they are pretty much awful. It takes so much practice and knowledge to use them well in Go.
>It is possible to do quite well, as demonstrated by {one of the other largest companies in the world}

FTFY