kbolino • yesterday at 4:38 PM

From nbio's README:

  For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues.

From gnet's README:

  gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled.
  [...]
  gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services.

Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface.

However, the net/http package is a different story. It indeed isn't very performant, though one should be careful to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers.

A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make.

[1]: https://pkg.go.dev/github.com/valyala/fasthttp

[2]: https://pkg.go.dev/github.com/gofiber/fiber/v3