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

161–170 of 236 posts

Re: Better HTTP server routing in Go 1.22

#161

Post by bborud »

shortrounddev2 wrote: post #113
badrequest wrote: post #104

Earlier quoted context omitted.

> Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? 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. > This kind of structured approach has fallen out of favor because it's become more popular to h…

> 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/framework about 20 years ago)

Re: Better HTTP server routing in Go 1.22

#162

Post by tptacek »

cfstras wrote: post #137
tptacek wrote: post #129

Earlier quoted context omitted.

I'm having trouble thinking of a mainstream production language with a stronger type system that could make a compile error out of the string argument passed to an HTTP router; can you think of one? Or of a non-string-typing for routes that solves the same problem, again in something people ordinarily use to deploy to production?

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?

Re: Better HTTP server routing in Go 1.22

#163

Post by yankput »

FiloSottile wrote: post #40
shp0ngle wrote: post #27

One thing I don't like about default ServeMux is that addresses are prefixes. So `mux.HandleFunc("/"...)` always handles _everything_. And there is no easy way to say "no, just handle exact matches, plus maybe ? queries". As gorilla/mux does. I don't think that is changed in the new go?

From the proposal: "There is one last, special wildcard: {$} matches only the end of the URL, allowing writing a pattern that ends in slash but does not match all extensions of that path. For example, the pattern /{$} matches the root page / but (unlike the pattern / today) does not match a request for /anythingelse."

Ahhh how did I miss that!!

That is amazing. Goodbye gorilla mux.

Re: Better HTTP server routing in Go 1.22

#164

Post by burnished »

jiehong wrote: post #153
avianlyric wrote: post #8

Earlier quoted context omitted.

Isn’t that just a consequence of Go’s backwards compatibility guarantee? Adding new arguments to the Mux interface would break existing code, given the method signature can’t be changed, these magic strings seem like a reasonable compromise. It not like HTTP verbs are going to change anytime soon, and it’s trivial to validate them during register, or via static analysis. So I’m not sure what value the use of constant…

Isn’t function overloading based on the number of arguments a thing in go? That wouldn’t break compatibility

Go does not have function overloading

Re: Better HTTP server routing in Go 1.22

#165

Post by [deleted] »

jbamsterdam wrote: post #59
mariusor wrote: post #31

Earlier quoted context omitted.

I would say that unless specified differently this bit of the documentation[1] still applies (second paragraph): > Longer patterns take precedence over shorter ones, https://pkg.go.dev/net/http#ServeMux

No, it does not. The length of the pattern isn't important anymore, only whether it overlaps with other patterns.

[deleted]

Re: Better HTTP server routing in Go 1.22

#166

Post by badrequest »

danpalmer wrote: post #72
badrequest wrote: post #53

Earlier quoted context omitted.

What common use-cases does it not support?

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…

This pattern already works and would work with this change, you'd just need to define `/foo/bar` first.

Re: Better HTTP server routing in Go 1.22

#167

Post by rob74 »

earthboundkid wrote: post #121
iudqnolq wrote: post #91

Earlier quoted context omitted.

This seems like an issue caused by registration at a distance. I'm new to go and it is one of the things that felt most wrong. I'm used to a router where you define a big list of routes all in one place, maybe in some DSL. That's very easy to refactor, and doesn't have any ambiguity. If a library wants a route registered it puts a snippet in the docs for users to copy. Go in general seems to value clarity over magic…

Go's flag, log, image, and sql packages all work this way, so it's not just the HTTP router. I sort of see both sides. Having implicit registration makes it very easy to have different teams working on different packages and you just import the package and it registers itself. But it also makes the behavior of the resulting final binary hard to understand and based on implicit code instead of explicit. I personally t…

Well, yeah, with the "implicit registration" model you can either split it up or do it in a central place, whereas if they would require you to do it in a central place, you wouldn't have that choice. It probably boils down to "library" vs. "framework" - Go's standard library doesn't want (as much as possible) to be a framework that forces you to do things its way, and as far as I'm concerned that's ok...

Re: Better HTTP server routing in Go 1.22

#168

Post by badrequest »

the_gipsy wrote: post #78
badrequest wrote: post #54

Earlier quoted context omitted.

Go is type safe.

The zero-values idea, nil, reflection and stringly-typing all over stdlib and the most popular libs makes go not type safe. Were you thinking of statically typed?

I genuinely have no idea what you're referring to by "stringly-typing all over stdlib". I've written Go every day for the better part of a decade and used the standard library the whole time. What standard library functions require passing in the string of a type?

Re: Better HTTP server routing in Go 1.22

#169

Post by bojanz »

creshal wrote: post #2

Will this finally end the eternal golang http router bikeshedding?

It doesn't have the performance or the features of something like Chi/Gin/Echo, so while it will improve the lives of people who prefer to stick to the stdlib, it probably won't convince many others.

Re: Better HTTP server routing in Go 1.22

#170

Post by conor- »

shortrounddev2 wrote: post #63

How did this kind of syntax become so popular? I think express is the first to do the scheme of: app.handleGet("/route/goes/here", (req, res) => { }); Which seems like it's useful for making really quick and dirty micro-services (nano-services, even), but I still vastly prefer the more declarative and modular schemes of bootstrap or asp.net: // Middleware automatically routes "/Foo" to FooController [Controller] publ…

I don't know about how it became popular, but personally I find the prior to be easier to parse quickly without having to learn what a handful of decorators do as well as cutting down on the amount of boilerplate required to write an HTTP handler.

Even .NET is moving towards your first example by providing minimal APIs that allow simple binding of a route to a handler function.

Post reply on HN