Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better HTTP server routing in Go 1.22

eli.thegreenplace.net

Post reply on HN
Print view View original

171–180 of 236 posts

Re: Better HTTP server routing in Go 1.22

#171

Post by burnished »

thiht wrote: post #115
imetatroll wrote: post #36

Man I really really dislike this proposal. Putting the http request method into the URI... an just sometimes... oh and maybe do "POST,PUT,PATCH /something". Just no thank you. Make a dedicated method that accepts http request method names if you must do something.

Why? It really doesn't change a lot. You can't "really dislike" the whole proposal for just a stylistic issue. > Make a dedicated method that accepts http request method names What problem does that solve compared to embedding the method in the string?

Yes, you can. Besides the API is more than just a stylistic issue.

The problem it solves is not having string typed stuff which is a consistent pain point where it happens.

Re: Better HTTP server routing in Go 1.22

#172

Post by burnished »

the_gipsy wrote: post #28

Stringly typed, runtime panics...

The panics occur on service startup which is good - you know immediately what is wrong and what went wrong.

The string typing thing.. I can understand why they did it even if it is not the thing I would have chosen.

Re: Better HTTP server routing in Go 1.22

#174

Post by tialaramex »

tptacek wrote: post #162
cfstras wrote: post #137

Earlier quoted context omitted.

Most languages with macro or templating should be able to define this behavior as a library. Rust and C++ come to mind, for example.

Can you provide an example of a Rust HTTP routing library that can generate a compile-time error for overlapping routes?

I don't know of one, but you seemed to doubt not that it's actively being done, but that it's even possible, which is a very different proposition.

Remember C++ actually implements checks at compile time for the modern std::format function. That is, if you mess up the text of a format string so that it's invalid, C++ gives you a compile time error saying nope, that's not a valid format.

You might think that's just compiler magic, as it is for say printf-style formats in C, but nope, works for custom formats too, it's (extremely hairy) compile time executed C++.

Re: Better HTTP server routing in Go 1.22

#175

Post by hknmtt »

hashworks wrote: post #155
hknmtt wrote: post #152

> Therefore, the new ServeMux documentation meticulously describes the precedence rules for patterns This is so backwards it's not even funny. It is supposed to be exactly the other way - conrete paths MUST TAKE PRECEDENCE over patterns.

In the example there are no concrete path, both have variables. Is there an example in the documentation that allows paths with variables precedence over concrete paths?

it is a quite form the article itself.

they say that get /foo/{id} takes precedences over path get /foo/23 or get /foo/bar

Re: Better HTTP server routing in Go 1.22

#176

Post by shortrounddev2 »

bborud wrote: post #161
shortrounddev2 wrote: post #113

Earlier quoted context omitted.

> You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience. So then it shouldn't be a problem for you to learn a new skill based on a very common pattern with many examples in different languages > This comes across to me as needlessly bitter to folks with less experience than you…

You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them. Perhaps you should be open to the possibility that you're wrong in assuming that? Perhaps there are people who dislike these kinds of designs precisely because they have experience with them? (hint: I wrote my first IoC container/fra…

> You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them.

You are wrong in your perception

Re: Better HTTP server routing in Go 1.22

#177

Post by pdimitar »

danpalmer wrote: post #44
figmert wrote: post #24

Earlier quoted context omitted.

The ownership transfer was publicly announced in quite a few places. Most notably gorilla's blog[0], but also on Reddit[1] as well as HN[2], though it didn't get much reaction on HN. [0] https://gorilla.github.io/blog/2023-07-17-project-status-upd... [1] https://www.reddit.com/r/golang/comments/1528e25/gorilla_web... [2] https://news.ycombinator.com/item?id=36935541

In my experience most developers are not connected to the development processes of their dependencies. Maybe they should be, I think there's an argument for it, but with so many dependencies there's only so much time and attention. I think any migration such as this should be done on the assumption that most people won't know it's happening.

Just a single data point: I am subscribing to new releases for a good number of projects but it's usually binaries and not libraries. Because I use them actively and I am interested in the changes and whether they are useful or harmful for me.

Libraries... yeah, too much work to monitor those, especially having in mind that the chances of a change affecting you negatively are likely in the fractions of a percent.

Re: Better HTTP server routing in Go 1.22

#178

Post by vlunkr »

fideloper wrote: post #5

Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…

I feel conflicted on it. I've abused routes in that way, but I've also been confused or encountered bugs because I didn't notice the conflict.

Re: Better HTTP server routing in Go 1.22

#179

Post by jupp0r »

fideloper wrote: post #5

Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…

It's a programmer's error, so it should lead to a panic. There is simply no reason to ever handle this at runtime (as opposed to network errors or other things that can go wrong during normal operation and should be handled at runtime).

Re: Better HTTP server routing in Go 1.22

#180

Post by danpalmer »

superb_dev wrote: post #142
danpalmer wrote: post #72

Earlier quoted context omitted.

The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…

The two routes `/foo/bar` and `/foo/*` are not ambiguous and would be allowed by the router

Are they? It seems that the latter matches the former. i.e. for the path `/foo/bar` there are 2 matching routes. One must take precedence, but this router doesn't appear to allow that.

This may just be a syntax thing, I was being loose with syntax, and meant that the `*` would match anything for the purposes of this example.

Post reply on HN