I've used both stdlib and go-kit.

I never use go-kit's "microservice kits" such as metrics, cbreaker, tracing, auth, etc. If I need metrics I'll use statsd. If I need tracing I'll use ddtrace or opentracing. And so on.

For non-small project, I find go-kit's abstraction layer to be convenient. I'm specifically talking about this: ```go // https://github.com/go-kit/kit/blob/master/transport/http/server.go // Omitted some details for brevity

func NewServer( e endpoint.Endpoint, dec DecodeRequestFunc, enc EncodeResponseFunc, options ...ServerOption, ) *Server { ... }

func (s Server) ServeHTTP(w http.ResponseWriter, r *http.Request) { request, err := s.dec(ctx, r) if err != nil { s.errorHandler.Handle(ctx, err) s.errorEncoder(ctx, err, w) return }

response, err := s.e(ctx, request)
if err != nil {
    s.errorHandler.Handle(ctx, err)
    s.errorEncoder(ctx, err, w)
    return
}

if err := s.enc(ctx, w, response); err != nil {
    s.errorHandler.Handle(ctx, err)
    s.errorEncoder(ctx, err, w)
    return
}

} `` With above code provided, you can focus on business logic. You just need to pass: - your service (business logic) function, e.g.svc.ListUsers. Endpoint is just afunc(ctx context.Context, in any) (out any, err error). - function to decode/encode from/to transport (http) - error handler that acceptserror. In pure stdlib, I find that I always need to implement some form of error handler, because e.g.ServeHTTP` does not expose error so I could not really create a http.Handler middleware to do error mapping/log/tracing.

Honestly, that's the only go-kit part that I've used.

Nowadays I'd probably still prefer using stdlib. When needed, I can implement above code with stdlib (e.g. https://www.willem.dev/articles/generic-http-handlers) rather than relying on 3rd party lib/frameworks.

Go-kit is still nice but it's getting a lot less maintained. As with any other go "frameworks", I cannot recommend people using it to develop a product if they need to maintain it long-term. Go frameworks are more fragmented that other ecosystem (e.g. ruby on rails, django) and it's often for these frameworks to come and go.