Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Bring HTTP path/regex based routing to the standard lib #38636
First of all, I Love Golang this is why I'm proposing this. You can laugh at it, down vote or what so ever.
Most of the time, I try to use the standard library as much as possible.
There's a difference between saying "This can be found in 3rd party library" vs "This is already available in the standard library".
The net/http package is almost robust, except for this one area. We want the standard library to be more robust.
Following https://golang.org/doc/faq#x_in_std, why does this really need to be in the standard library?
It's true that complex HTTP servers likely need a fancier router, but they probably also need other fancy things that don't need to be in
You could argue that
So, if you're serious about this proposal, I think you should really specify what changes to the API you're suggesting.
@mvdan your point of "unable to specify how the standard library router should look like when we say more powerful" is vague. Does it mean, we can not standardize how the standard library should look like?
If it is, then how did the Go team standardized the template (html or text) syntax when there are multiple other ways of doing the exact thing (like pug, handlebars etc)?
This is just an example. Not able to standardize a new feature is a huge mental restriction. The way the template language syntax was standardized and placed in the library is very much same for any case of making/adding something to the standard library.
Why it should be me to propose that API? It's already there in countless 3rd party libraries. Take a look at them and you should have a firm believe that "how the API will look like". This is such a basic feature. And when you advertise "the language for cloud native apps" but has lacking in simple as the net/http router, it sounds really silly.
If you guys still unsure about how it should look like, then I'm signing off. It's awful to talk about this when you know what I mean but acting like you don't understand it.
I'm not clear on exactly what you're proposing. Are you saying we should include the API from multiple third party libraries at once? Or that we should look at many of them, and come up with some sort of unified API on our own?
A proposal should propose a very specific and detailed change to Go. It seems to me like "add a regex-based router to the standard library" is too generic for any work to be considered or done. Hence why I'm asking that you propose a specific change that can be evaluated.
Look at it this way. The core Go team is a relatively small number of people who has to deal with hundreds of proposals and thousands of issues. What you are suggesting is at this point very vague.
If your suggestion is: make net/http router work exactly like the gorilla/mux router, then our first response is going to be the FAQ cited above: https://golang.org/doc/faq#x_in_std. This isn't a casual or superficial objection: the gorilla/mux package already exists. You can already use it. There has to be a reason to bring it into the standard library. What is that reason?
Perhaps the discrepancy is that you started off by saying "Most of the time, I try to use the standard library as much as possible." Our stance is as cited in the FAQ: "Most new code should live outside of the standard library and be accessible via the go tool's go get command."
There is definitely a tension between "put everything useful in the standard library" and "encourage a thriving ecosystem of third party packages." We have to find the right balance between those choices.
For this proposal, you'll need to explain why the balance is in power of putting more into the standard library. And to make that argument you'll need to show exactly how the standard library should change: what new functions it should have, and how they should behave.
But start by saying why the balance here tips toward moving more functionality into the standard library. The only clear reason I see here is "We want the standard library to be more robust." Let me counter that by claiming that adding more features, especially to a complex package like net/http, makes it larger, harder to test, harder to understand, and, in my opinion, actually less robust.