> There is no place for gRPC in NGINX.

Meh. There's place in NGINX for Adobe HDS[0], flv streaming[1], JWT[2], memcached[3], flash mp4 pseudo-streaming[4] and XLST[5].

Hell, spdy draft 3.1 is still supported[6]…

[0] http://nginx.org/en/docs/http/ngx_http_f4f_module.html

[1] http://nginx.org/en/docs/http/ngx_http_flv_module.html

[2] http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html

[3] http://nginx.org/en/docs/http/ngx_http_memcached_module.html

[4] http://nginx.org/en/docs/http/ngx_http_mp4_module.html

[5] http://nginx.org/en/docs/http/ngx_http_xslt_module.html

[6] http://nginx.org/en/docs/http/ngx_http_spdy_module.html

That's all very well, but Adobe don't have aspirations of running the entire internet.

Same can be said for all the other things you hastily rushed to link to, those are not infrastructure protocols

Note that gRPC was created by Google but was contributed to CNCF last year. https://www.cncf.io/blog/2017/03/01/cloud-native-computing-f...

It's now being used by tons of different companies, including Google competitors like Microsoft Azure.

Disclosure: I'm the executive director of CNCF.

What are better options?

The difference is between open (which gRPC is) and proprietary. The origination doesn't really matter. Lots of great open tech has come from Google, Microsoft, Apple, Amazon, Facebook, Netflix, Github, etc. Almost all the big projects started at a big company that needed to get something done and had the resources to create something new.

I'd rather the industry pick something and actually standardize instead of reinventing the same thing repeatedly just for some philosophical reasons.

I agree with the industry picking something part.

The part I'm not keen on is nobody asks for a discussion on things anymore, they just check stuff in and it becomes a defacto standard.

Which can be okay... but I'm not a fan of foie gras for a reason

Ok, but what do you find are better options then? If you have examples then we can discuss why they haven't taken off as popular standards.

> nobody asks for a discussion on things anymore, they just check stuff in and it becomes a defacto standard

Google doesn't own Nginx, so I find it hard to believe that there were no discussions and they just went ahead and "checked stuff in".

There might be some problems with it, it is not perfect, however it is already open, not bound to Google and we used in internal projects, and multiple very large projects also use it freely. I really like the strong typing and the ability to bi-directional streams and finally code generation for various languages make it very okay. Our main product was Go, but a part had to be Java and the integration was very easy because we used gRPC. Not that it cannot be achieved by other tools and frameworks, gRPC is already popular and well performing enough for most people.

"Not cool" is telling the long-term maintainers of software what "has no place in their software" and not to fulfill user/customer requests because that'd be helping a company you don't like.

Google's influence in many parts is a problem, but people using an internal protocol they've made up is basically irrelevant IMHO, unless you have a really good argument why it is a problem.

> Besides that, protobuf and its ilk aren't even good or modern.

What would you consider "good" or "modern"? JSON?

Just out of curiosity, what's a modern alternative to protobufs?

I would also like to know why you don't consider it 'modern' and how you would define modern-ness in this context.

I answered above.

https://google.github.io/flatbuffers/ and https://capnproto.org/ are both successors to protobuf

I don't think they are successors, just different. Protobuf is a sparse wire format, whereas FlatBuffers and Cap'n Proto use a fixed-layout wire format. There are plusses and minuses to both. I wrote a little bit about this here: https://news.ycombinator.com/item?id=6329041#6330426

(Disclosure: I work at Google on the protobuf team)

gRPC uses Protobuf version 3. Both it and CapnProto are successors to Protobuf version 2. Flatbuffers is not a successor but is targeted at a different use case.

One that is type extensible, not brittle and based on schemas with fragile language integration tools, is streamable down to the atom level, naturally sortable, homoiconic in nature and efficient to produce and consume.

Such things exist, I'm not just rattling off buzzwords.

The main thing is protocols are serious business and people, especially any of the big five shouldn't get to own them just because it suits a business interest.

It's easy to argue you are just rattling off buzzwords if you don't provide examples.

I would also argue that not based on a schema is even more brittle as you end up implementing validation logic and client marshalling that the schema would allow you to just generate.

Name some. Seriously, I'm interested in protocol design, so I'll read them. But also, yeah, just declaring that things exist is kind of unhelpful.

> Such things exist, I'm not just rattling off buzzwords.

you are though ...

Is Google behind this integration effort?