proposal: net/http: merge performance benefits of fasthttp into stdlib

[Linvas]

most people think fasthttp great , is it possible official developer try to use fasthttp code to make golang httpserver more better?

[dsnet]

\cc @bradfitz

[bradfitz]

No, we're not going to have two separate HTTP implementations and API in the standard library, sorry.

Also, fasthttp makes some severe API cleanliness compromises in the name of speed.

For Go 2, I'd like to change some of the public HTTP API to hide more of the internals to enable some optimizations we can't do today, but not before Go 2.

[as]

@bradfitz

I realize the issue is closed, but is it possible to enumerate some of those compromises before closing the issue? These types of libraries proliferate by advertising safety and speed. More often than not, one or more of those assumptions are false. The maintainers play catch-up with stdlib as issues accrue in the third party packages, along with consumers of those libraries.

It would be of great benefit to highlight some of the compromises fasthttp makes in this issue so people searching for this topic can see the gory details rather than a brief synopsis in the future.

[bradfitz]

Compromises:

• its use of unsafe
• the size of its API: https://godoc.org/github.com/valyala/fasthttp
  • why does it have IPv4 parsing functions? https://godoc.org/github.com/valyala/fasthttp#ParseIPv4
  • or uint64 parsing? https://godoc.org/github.com/valyala/fasthttp#ParseUfloat