Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Linvas opened this issue Dec 1, 2017 · 4 comments

Comments

Projects
None yet
5 participants
@Linvas
Copy link

commented Dec 1, 2017

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

@Linvas Linvas 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 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

@gopherbot gopherbot added this to the Proposal milestone Dec 1, 2017

@gopherbot gopherbot added the Proposal label Dec 1, 2017

@dsnet

This comment has been minimized.

Copy link
Member

commented Dec 1, 2017

\cc @bradfitz

@bradfitz

This comment has been minimized.

Copy link
Member

commented 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.

@bradfitz bradfitz closed this Dec 1, 2017

@as

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2017

@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

This comment has been minimized.

Copy link
Member

commented Dec 1, 2017

Compromises:

@golang golang locked and limited conversation to collaborators Dec 1, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.