// the find
cloudwego/hertz
Go HTTP framework with high-performance and strong-extensibility for building micro-services.
Hertz is a Go HTTP framework from ByteDance, built on top of their own Netpoll network library instead of Go's standard net package. It sits between Gin (simple, standard) and gRPC gateway territory — aimed at teams running high-throughput internal microservices who need more control than Gin gives but less complexity than rolling their own. Battle-tested at ByteDance scale.
1. Netpoll integration is the real differentiator — using epoll-based I/O with goroutine pools instead of one-goroutine-per-connection gives measurable latency wins under high concurrency, not just benchmark theater. 2. The hz code generator supports both Protobuf and Thrift IDL, which is practical for ByteDance-style RPC-heavy orgs; generating handler stubs and router wiring from an IDL is a real productivity win. 3. Extension ecosystem in hertz-contrib is well-organized — registry integrations (nacos, etcd, consul, zookeeper, polaris) cover the service discovery landscape you'd actually encounter in a Chinese cloud or on-prem stack. 4. Network library is swappable at runtime — you can fall back to standard Go net if Netpoll causes issues on a specific platform, which is a sensible escape hatch.
1. The community is predominantly Chinese — issues, discussions, and even a lot of the documentation is in Chinese first. If you're not reading Chinese, you're a second-class citizen when something breaks at 2am. 2. Netpoll doesn't support Windows, so if any developer on the team works on Windows, they silently fall back to Go net without knowing it — or hit build issues they have to debug themselves. 3. HTTP/2 and WebSocket are in separate contrib repos, not in core — they lag behind the main repo and have had periods of being out of date. For anything beyond HTTP/1.1 you're taking on maintenance risk. 4. Tight coupling to ByteDance's internal tooling assumptions (Thrift, their service mesh) means some abstractions feel foreign if you're coming from a standard Go or gRPC stack — the learning curve is steeper than it looks from the API surface.