Live data from Hacker News

Mux – A lightweight, fast HTTP request router for Go

github.com

41–50 of 80 posts

Re: Mux – A lightweight, fast HTTP request router for Go

#41
post #40
post #37

Earlier quoted context omitted.

Why is a trie obviously better then a hash map?

Fixed lookup time. A trie (aka radix tree) 3 levels deep with 1 million entries has the same lookup time as a 3 level deep trie with 5 entries.

Isn't the same thing true for a 3 level deep hashmap of hashmaps?

Re: Mux – A lightweight, fast HTTP request router for Go

#42
post #29

Earlier quoted context omitted.

Looks like it uses regexp... There isn't any benchmark code as one would expect when making a claim that it's "fast".

Go regexps are slow ( https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...

Regexes are the problem, because they're simply the wrong tool for the job.

Re: Mux – A lightweight, fast HTTP request router for Go

#43
post #5

I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux

That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.

Fair point, but this post title should read "donutloop/mux – A lightweight, fast HTTP request router for Go", then :)

Re: Mux – A lightweight, fast HTTP request router for Go

#44
post #28

Earlier quoted context omitted.

Looks like it uses regexp... There isn't any benchmark code as one would expect when making a claim that it's "fast".

Regexp definitely isn't something you'd want to be using if you're primary goal is speed. When running tight loops in string parsing I've found using string splitting and then cycling through the range of indices in a slice was several times faster than Regexp matching. Obviously performance difference will vary depending on the expression and application but that was enough to convince me to think twice about future…

That depends entirely on the regex implementation. If the implementation uses a DFA to match multiple regexes simultaneously then the performance will be as good as a trie because a DFA is more or less a trie.

Re: Mux – A lightweight, fast HTTP request router for Go

#45
post #16
post #15

My favourite current HTTP request router is https://github.com/pressly/chi The list of those using it in production includes: - Pressly - Cloudflare - Heroku - 99designs - Origami - IT Jobs Watch - CrowdRiff At Cloudflare it's our default router for internal APIs, which are all written in Go. (and yes it uses a trie)

Do you know how it stacks up to httprouter for example? We can run benchmarks all day but it would be cool if you happened to have some real production statistics, by any change?

httprouter is unforgiving with routes. IIRC, having both of these routes are not allowed

    /users/:id
    /users/create
Seems like a common use case.

Re: Mux – A lightweight, fast HTTP request router for Go

#46
post #5

I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux

I typically read the HN comments before clicking on a link, and I actually thought this _was_ a post about gorilla/mux until I got to your comment.

Same here. I was working with gorilla/mux 2 min ago with some "legacy" code and saw this. Thought to myself "huh it might be some good new changes with gorilla/mux"

Re: Mux – A lightweight, fast HTTP request router for Go

#47
post #37
post #2

Does it use a trie? If not, it probably should. Here's a wonderful talk on using that datastructure (with go) for the gov uk url router: https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-... The Vulcan proxy from Mailgun does the same thing: http://vulcand.github.io/proxy.html#route It looks like it doesn't, so existing open source golang url routers will perform much better, contrary to this post. The one…

Why is a trie obviously better then a hash map?

A trie is O(k), where k is the length of the key on inserts and deletes. Generally, any hashing algorithm is also O(k) with the additional overhead of the lookup in the table. This also ignores that most hashes have only amortized O(1) inserts. A trie usually also exhibits better memory locality and caching behavior. Also, a trie (like most tree data structures) can be implemented in a lock-free format fairly easily.

Re: Mux – A lightweight, fast HTTP request router for Go

#48
post #42
post #29

Earlier quoted context omitted.

Go regexps are slow ( https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...

Regexes are the problem, because they're simply the wrong tool for the job.

> Regexes are the problem, because they're simply the wrong tool for the job.

for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".

Re: Mux – A lightweight, fast HTTP request router for Go

#49
post #48
post #42

Earlier quoted context omitted.

Regexes are the problem, because they're simply the wrong tool for the job.

> Regexes are the problem, because they're simply the wrong tool for the job. for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".

[deleted]

Re: Mux – A lightweight, fast HTTP request router for Go

#50
post #5

I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux

Luckily because of how packages are in go this won't be too much of an issue. Simply have to refer to gorilla/mux or donutloop/mux specifically.
Post reply on HN