You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
most people think fasthttp great , is it possible official developer try to use fasthttp code to make golang httpserver more better?
The text was updated successfully, but these errors were encountered:
athsx
changed the title
Is it any possible merge fasthttp into the office httpserver
Is it any possible merge fasthttp into the officail golang http packages?
Dec 1, 2017
dsnet
changed the title
Is it any possible merge fasthttp into the officail golang http packages?
proposal: net/http: merge performance benefits of fasthttp into stdlib
Dec 1, 2017
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.
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.
most people think fasthttp great , is it possible official developer try to use fasthttp code to make golang httpserver more better?
The text was updated successfully, but these errors were encountered: