It can be surprising how little code you're actually using from the Go-Kit project, and how it's really more of a structure for your app.

It will not save you time typing: each route can have a transport request decoder and response encoder (encoder's are often shared), a request and response type, the actual business logic, a function that takes the request struct, applies it to the business logic function and returns a response object, a function that takes the previous function and connects it with the transport machinery (building the actual endpoint), and possibly middleware implementations.

However, by teasing all of these things apart from the very beginning it's very easy to come back later and add a circuit-breaker, or (as the article says) switch your transport from HTTP to grpc (or support both).

It will lock you down, as it's very hard to migrate from go-kit.

IMHO, it only brings problems.

I've been using it for a few months, and it's pretty great.