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

191–200 of 236 posts

Re: Better HTTP server routing in Go 1.22

#191

Post by drdaeman »

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

Ideally, this should be the default behavior, i.e. "/foo/" matching only "/foo/" and nothing else. And if one wants a prefix they should be able to explicitly spell it out like "/foo/{**}".

But that’s not backwards-compatible, sadly, so this is going to remain a historical wart.

Re: Better HTTP server routing in Go 1.22

#192

Post by drdaeman »

ilyt wrote: post #60
gavinray wrote: post #47

It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/path") Rather than the current: ("GET /path") Odd.

It's mistake they can't fix without breaking existing code or introducing new function. But I'd prefer just a bunch of mux.GET/mux.POST/etc functions instead of that.

You’ll need new HandleMethod(method, uri, …) anyway, because otherwise you won’t be able to support any less common or non-standard methods.

Re: Better HTTP server routing in Go 1.22

#193

Post by arp242 »

Cupprum wrote: post #143
arp242 wrote: post #127

Earlier quoted context omitted.

It's a bit of a catch-22: 1. I want to send a PR! 2. Project doesn't seem very active, so never mind. Plus I'm not checking if any of my dependencies need help every day. I took over fsnotify after it was archived because I just didn't know they needed help. Last guy spent about 5 years looking for someone to take it over. I wouldn't have minded doing it before, but ... you do need to know about it.

How much time do you spend working on fsnotify if i may ask.

I spent quite a bit of time on it last year, a few weeks of full-time work or so, but haven't spent anything on it for quite a while. There's a bunch of things I'd like to do so I'll probably spend another burst of effort in the future.

It's kind of an annoying project to work on because everything is platform-dependent (and at times fickle) so you can't "just" run "go test ./..." but really do need to test it on all platforms. BSD and illumos aren't too much trouble, macOS is already rather painful (slow), and the experience of running Windows is not something I'm able to describe using only polite terms.

Re: Better HTTP server routing in Go 1.22

#194

Post by majewsky »

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?

Type safety is a spectrum, not a binary choice. Having used Go for 10 years now, next to other popular languages like JS and Python, I think it squarely falls into the "more type-safe than not" half of the spectrum. But it's definitely a positive development that, as this discussion shows, the Overton window of type safety is shifting towards the safer part of the spectrum.

Re: Better HTTP server routing in Go 1.22

#195

Post by iudqnolq »

numbsafari wrote: post #112
iudqnolq wrote: post #95

Earlier quoted context omitted.

Why even allow registrations at a distance? I'm a complete go beginner but that feels more in the spirit of go to me: making you do something a little annoying that ends up being clear and simple. Of course it's too late now but I'm surprised this API was ever considered because it seems obviously scary and wrong to let a dependency just create it's own routes.

How would you propose they block it? Can you provide an example from another language where it is blocked?

> How would you propose they block it?

Rather than have a single global mux have a mux instance. You call methods on that instance to register routes and then serve the instance. This means you can use your ide to find all routes.

Re: Better HTTP server routing in Go 1.22

#196

Post by troupo »

numbsafari wrote: post #125
troupo wrote: post #118

Earlier quoted context omitted.

Hard panic in a "not simple app with large codebase" app because you couldn't match a route is amateur hour.

I think you are vastly oversimplifying what has been said or why it works the way that it does. I really recommend you read the design document and reasoning, as it is rather clear why they are doing it the way that they are. If you have a cogent contribution to the discussion, please do share.

Others have already contributed more than enough.

People's willingness to defend any and all of go's dubious decisions is really baffling.

Re: Better HTTP server routing in Go 1.22

#197

Post by qaq »

austinpena wrote: post #20
qaq wrote: post #16

Good one less external dependency. As a side note sqlc + postgres + templ (kindah jsx for go) + htmx + tailwinds has being extremely productive stack to develop in

I really wish that templ had intellij support! Love the idea

I think that is in the works ? VS Code support is top notch

Re: Better HTTP server routing in Go 1.22

#198

Post by troupo »

tptacek wrote: post #129
bananapub wrote: post #124

Earlier quoted context omitted.

Go as a language is generally not sophisticated enough to do that sort of thing. A counter- and/or example of this is what Service Weaver does to try to bomb builds when generated files are older than their dependencies.

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?

> that could make a compile error out of the string argument passed to an HTTP router

For example, Phoenix Verified Routes in Elixir: https://hexdocs.pm/phoenix/Phoenix.VerifiedRoutes.html

Re: Better HTTP server routing in Go 1.22

#199

Post by unchar1 »

tptacek wrote: post #129
bananapub wrote: post #124

Earlier quoted context omitted.

Go as a language is generally not sophisticated enough to do that sort of thing. A counter- and/or example of this is what Service Weaver does to try to bomb builds when generated files are older than their dependencies.

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?

Typescript's type system is known to be turing complete and people have implemented things such as sorting/tree-walking just using types (i.e. during compile time) [1].

I'd imagine something like this should be possible as well, but I'm not sure it would be worth it, considering the effort it would take to implement.

[1]: https://twitter.com/anuraghazru/status/1511776290487279616

Re: Better HTTP server routing in Go 1.22

#200

Post by the_gipsy »

majewsky wrote: post #194
the_gipsy wrote: post #78

Earlier quoted context omitted.

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?

Type safety is a spectrum, not a binary choice. Having used Go for 10 years now, next to other popular languages like JS and Python, I think it squarely falls into the "more type-safe than not" half of the spectrum. But it's definitely a positive development that, as this discussion shows, the Overton window of type safety is shifting towards the safer part of the spectrum.

That's true. From that perspective it is safe. But from the perspective of for example Elm and Rust, I would say go ends up in the other half of the spectrum - but still close to the middle.
Post reply on HN