Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC: The Bad Parts

kmcd.dev

Post reply on HN
Print view View original

221–230 of 230 posts

Re: gRPC: The Bad Parts

#221

Post by kaba0 »

hot_gril wrote: post #212
kaba0 wrote: post #191

Earlier quoted context omitted.

How is it on life support, when it’s by far the biggest server-side language, running basically every top companies’ business critical infrastructure? Also, annotations are just metaprogramming, which can be tastefully applied.

Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.

That’s not due to the language, but due to the business domain (I assume web development). In this domain almost every framework, regardless of language, will heavily use metaprogramming, see django, etc.

Re: gRPC: The Bad Parts

#222

Post by dcow »

bunderbunder wrote: post #209
dcow wrote: post #176

Earlier quoted context omitted.

You can get this without gRPC, though. Any IDL with codegen will do. My journey was that of gRPC fanatic to hardened skeptic. After one too many “we’re doing it this way because that’s what Google wants (and thus my promotion needs)” decisions from gRPC “maintainers”, I can’t stomach yielding so much control to a network request framework anymore. There’s something to be said for just making http requests using your…

Avoiding request boilerplate, in and of itself, is a benefit I could take or leave. Boilerplate request/response code is boring, but not actually time-consuming to write. What I really like about the IDL and codegen is that it makes inter-team coordination easier. Comments in the .proto file is much nicer for documentation than, e.g., Swagger docs. And it gets even better when you're negotiating protocol changes amon…

Maybe hardened skeptic is HN hyperbole. I tend to avoid adding it to every project I touch these days, though.

Re: gRPC: The Bad Parts

#223

Post by EdwardDiego »

metadat wrote: post #129
doctorpangloss wrote: post #109

Earlier quoted context omitted.

Another point of view is, don't use Bazel. In my experience, Gradle is less of a headache and well supported.

Gradle is an anti-pattern. Just stick with Maven and live a happy life. As someone who's used Gradle tons, 6 months ago I wrote in detail about why not gradle: https://news.ycombinator.com/item?id=38875936 Gradle still might less bad than Bazel, though.

I'm firmly in the Maven is better than Gradle camp. Yes, it's less flexible, that's why I like it.

Gradle might be better if it wasn't a poorly documented Groovy/Kotlin DSL where everything is a closure, but I do like the fact that if you want to do something in Maven you need a plugin that couples to known points in the lifecycle. It makes it explicit what is doing what and where.

And fully agree on the incredible pain of Gradle upgrades.

Re: gRPC: The Bad Parts

#224

Post by TwentyPosts »

hot_gril wrote: post #157
kortex wrote: post #154

Earlier quoted context omitted.

Any time you have a scalar/measurement number, basically any value with physical units, counts, percentages, anything which could be in the denominator of a ratio, those are all strong indicators of a "semantic zero" and you really want to tell the difference between None and 0. They are usually floats, but could be ints (maybe you have number_of_widgets_online, 0 means 0 units, None means "idk".)

What's the difference between none inches and 0 inches? Might need a concrete example. We deal with space a fair amount and haven't needed many optionals there.

They just gave a concrete example: The difference between "we don't know" and "we know that it's zero".

Here's another fun one: I've seen APIs where "0.0" was treated as "no value, so take the default value". The default value happened to be 0.2.

Re: gRPC: The Bad Parts

#225

Post by 8n4vidtmkvmk »

dcow wrote: post #179
jscheel wrote: post #53

The tooling around gRPC with bazel when using python is so bad it’s almost impossible to work with, which is hilarious considering they both come from Google. Then I had additional problems getting it to work with Ruby. Then I had more problems getting it to work in k8s, because of load balancing with http/2. Combine those issues with a number of other problems I ran into with gRPC, and I ended up just building a sma…

At Google scale, I’m sure excruciatingly horrible builds are no worry because they’re some other team’s problem. I hope JSON-RPC eats the world.

No, it's still horrible, we just don't understand why because some other team maintains it. We just suffer the long build times by killing time on memegen or visiting the MK.

Re: gRPC: The Bad Parts

#227

Post by thinkharderdev »

arp242 wrote: post #205
thinkharderdev wrote: post #203

Earlier quoted context omitted.

You need all the same stuff with a REST API only instead of using tooling to codegen all the boilerplate you have to write it by hand (or use janky OpenAPI code generators which, in my experience, rarely work very well). I am increasingly annoyed by protobuf as a standalone format but given the choice to create a new API using gRPC (where I can spend five minutes writing some proto files and then codegen all the boil…

> You need all the same stuff with a REST API That's just not true. A straightforward REST API is significantly simpler and less code throughout.

How exactly? If we take the simplest possible "hello world" service, then protoc generates all the code for a gRPC service without you having to manually type anything

Re: gRPC: The Bad Parts

#228

Post by jakjak123 »

kortex wrote: post #219
jakjak123 wrote: post #155

Earlier quoted context omitted.

I think your anecdote is rather weak with regards to the way protobuf works, but to entertain, why would a confidence of 0.0 be so different from None? 0.0 sounds very close to None for most numerical purposes if you ask me. Wait, are you using Python?

Yes it was python but that has nothing to do with it. Same would happen in go, rust, R, or matlab. Correct answers: 1.0, 0.0, 1.0 Confidence from algo: 1.0, 0.0, n/a Confidence on the wire: 1.0, 0.0, 0.0 Score after bug: 66% Score as it ought to be scored: 100% It was enough to make several algorithms which were very selective in the data they would attempt to analyze (think jpg vs png images) went from "kinda crap"…

Well, only in python is that N/A value also a float. In protobuf, go or Java for that matter, that data model must somehow be changed to communicate the difference.

If you had use 3 float values in Go or Java you would have had the same problem.

Re: gRPC: The Bad Parts

#229

Post by hot_gril »

kaba0 wrote: post #221
hot_gril wrote: post #212

Earlier quoted context omitted.

Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.

That’s not due to the language, but due to the business domain (I assume web development). In this domain almost every framework, regardless of language, will heavily use metaprogramming, see django, etc.

Javascript and Golang didn't need metaprogramming for this. Some of this has to do with not adhering to the OOP-everywhere model. Where's the metaprogramming in Django?

Re: gRPC: The Bad Parts

#230

Post by UnluckySelf »

fisian wrote: post #69
dudus wrote: post #43

Earlier quoted context omitted.

If I remember correctly the initial version allowed required fields but it caused all sorts of problems when trying to migrate protos because a new required fields breaks all consumers almost by definition. So updating protos in isolation becomes tricky. The problem went away with all optional fields so it was decided the headache wasn't worth it.

That decision seems practical (especially at Google scale). I think the main problem with it, is that you cannot distinguish if the field has the default value or just wasn't set (which is just error prone). However, there are solutions to this, that add very little overhead to the code and to message size (see e.g. [1]). [1]: https://protobuf.dev/programming-guides/dos-donts/

But you can distinguish between default and unset: all optional fields have has_ method associated with them: https://protobuf.dev/reference/cpp/cpp-generated/#fields
Post reply on HN