But FB also uses the monorepo tactic, and they have a bunch of fancy PL stuff. And Jane Street does too (though I guess we but one fancy PL). Honestly, I don’t see the connection.
Maybe it’s because FB had big PL related challenges to face, due to its
early focus on php which tends to be… messy. That lead to Hack and,
later, to Flow, and maybe served as a trojan camel^W horse for OCaml
people? Google has very conservative language choices but never had such
a need to use cleaner languages 
That’s not quite how it looks to me. Your pull request wasn’t specifically to support OCaml, which is not a first-class programming language at Google, but to correct deficiencies in the C interface— and C/C++ is a first-class programming language at Google. Of course, your changes were welcome. And yes, of course you’re invited to keep them informed about progress in your completely external project developing OCaml bindings for gRPC— provided you aren’t asking for any OCaml logic to be introduced directly into a package so widely used within Google.
Because that would get you a completely different response.
Which is to say: nobody here should waste any energy trying to get OCaml into the gRPC reference implementation. As it happens, I completely agree with others here that gRPC support for OCaml programmers could be hugely important to growing our community. I just don’t think it will happen at all if it requires active collaboration with the maintainers of the gRPC reference implementation.
To add to what @c-cube wrote, I’d also point out that FB inadvertently hired some people with serious expertise in Haskell and OCaml, who were much better evangelists internally than the ones at Google have been. Not only did they have a greater need for better programming languages, due to having started on PHP, they also had the advantage of some serious internal talent who were right there with solutions when they needed them. Neither of those are true about Google, so the barriers to adoption of new languages posed by a monorepo tactic are more formidable at Google than at FB or Jane Street or or or…
I don’t get what the monorepo has to do with anything. There are already multiple languages in Google’s monorepo.
Also, I think discouraging people from building a native OCaml grpc on the basis of vague comments about how Google hates OCaml is unreasonable. If someone wants to create it, let them. Don’t tell people not to write software they need and want.
I started on the implementation of parsers/serializers of HTTP/2 frames using Angstrom and Faraday (https://github.com/anuragsoni/h2). The actual parser/serializer is in a usable state, but i’ll still need to spend some time to add more tests to compare the behaviour with other known implementations. It should at least serve as a starting point for experimenting with the actual HTTP/2 state machine (That’s the next item I want to explore)
Amazon uses Haskell intensively I think.
They hired a few functional programmers.
use buckescript to compile to node js, then you can use grpc. You also have the whole nodejs ecosystem.
This isn’t an answer to your question, but I’ll ask it anyway: Have you thought about using Thrift? B/c
(a) superior to GRPC in every way, other than not being GRPC (hence, not usable to talk to Google’s servers)
(b) has an Ocaml binding
Why is GRPC inferior to Thrift? Well, here’s a comment I appended to an issue about it: https://github.com/grpc/grpc/issues/7834#issuecomment-396413561
The answer I got back from a “product manager” at Google was “gosh, we really want to improve”. But the thing is, they don’t want to improve: the purpose of the OSS GRPC implementation is NOT to help people write great servers, but instead to help people write code that works well with Google. That comment has lots of details, which all came out while I was consulting for a major Silicon Valley I/T company building server infrastructure on GRPC. It was a nightmare.
Heck, the mere fact that GRPC uses HTTP/2 should tell you something: nobody, and I mean nobody should be building high-performance distributed systems on HTTP, which is only suitable for public-facing ingress systems.
Is there a description somewhere (a -neutral- description) of the GRPC protocol? By which I mean, the framing and callstream wire-protocols, that surround the protobuf3 wireline for messages?
I don’t recall there being one, but I could be mistaken.
ETA: nevermind, I found: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
ETA[2]: oh sigh, they don’t actually describe how they map streams onto HTTP/2. As with (it seems) everything from Google, “sometimes the best documentation is the source code”. I don’t object to that, but … when you’re trying to create a public standard, you really need to do better [, Google].
There is a new discussion with almost ready implementation in pure OCaml: gRPC server and client in OCaml