Twirp _is_ great. For unary RPC, Connect is similar: using the Connect protocol, it works over HTTP/1.1 or HTTP/2, doesn't require any special networking infra, and has first-class support for JSON payloads. In short, `curl | jq` works again.

To us, the biggest difference is that Connect _also_ supports the gRPC and gRPC-Web protocols. That lets your code interop with a much, much larger ecosystem of tools and systems, many of which are better-supported than their Twirp equivalents.

We designed the Connect protocol and the Go APIs to make multi-protocol support seamless. Server-side code supports the Twirp-like protocol and the gRPC protocols simultaneously by default. Clients can switch protocol with one option, no other code changes required.

twirp is great. You get all the benefits of a schema'd/proto'd wire format (like automatic client library generation), but using standard http infrastructure (web servers, loadbalancers, etc etc) without the custom grpc routing stuff.

I think another differentiator is support for streaming. Tbh I am shocked at the number of folks that use streaming, but alas.

It was the #3 issue opened on twirp repository, but they never settled on a solution.

https://github.com/twitchtv/twirp/issues/3

One super underrated feature Connect offers for Go devs is access to the request/response headers. No more plumbing incoming/outgoing context :phew: