Live data from Hacker News

Mux – A lightweight, fast HTTP request router for Go

github.com

71–80 of 80 posts

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

#71
post #66
post #65

Earlier quoted context omitted.

I think you're missing the point of the discussion entirely. When you're more or less doing string splitting, using regex (regardless of performance) really is the wrong tool for the job. In this use case (url routing) a tree based data structure aka a trie or radix tree, are better suited.

> I think you're missing the point of the discussion entirely. When you're more or less doing string splitting, using regex (regardless of performance) really is the wrong tool for the job. In this use case (url routing) a tree based data structure aka a trie or radix tree, are better suited. I'm not missing the point of the discussion. Using regex is not the wrong tool for the job. You deemed it the wrong tool for t…

If you use a broken hammer to attempt to insert a screw, you're crazy for using the hammer, not because it's broken.

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

#72
post #22

Earlier quoted context omitted.

What? No! There's no indication at all these two libraries are compatible - why would you want two completely disparate projects to give some indication they support the same interface?

Because many of the base infrastructure libraries are compatible as long as they used interfaces ( grumble grumble os.File ). I would be very surprised if this doesn't implement net/http/ServeHTTP

It doesn't matter what it's named though, you can always alias the import.

If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux.

Import name similarity is a terrible argument for picking a name.

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

#73
post #71
post #66

Earlier quoted context omitted.

> I think you're missing the point of the discussion entirely. When you're more or less doing string splitting, using regex (regardless of performance) really is the wrong tool for the job. In this use case (url routing) a tree based data structure aka a trie or radix tree, are better suited. I'm not missing the point of the discussion. Using regex is not the wrong tool for the job. You deemed it the wrong tool for t…

If you use a broken hammer to attempt to insert a screw, you're crazy for using the hammer, not because it's broken.

> If you use a broken hammer to attempt to insert a screw, you're crazy for using the hammer, not because it's broken.

Are you resorting to insults now ? or is the typical hate and mean spirit of the Go community ? a router isn't a hammer. And I could care less about your opinion.

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

#74
post #68
post #66

Earlier quoted context omitted.

> I think you're missing the point of the discussion entirely. When you're more or less doing string splitting, using regex (regardless of performance) really is the wrong tool for the job. In this use case (url routing) a tree based data structure aka a trie or radix tree, are better suited. I'm not missing the point of the discussion. Using regex is not the wrong tool for the job. You deemed it the wrong tool for t…

FWIW If the router was in C or Rust or .net (which has a Jit for their regex engine) I would still tell you Regex is the wrong tool for splitting a URL on '/'. How many people have to tell you facts for you to believe them? Forget your pointless anti-go bias. A regex, while perfectly good for certain types of pattern matching makes no sense here. I often have taught the same lesson to my junior colleagues who use reg…

> How many people have to tell you facts for you to believe them? Forget your pointless anti-go bias

Because a few people on HN is the consensus ? give me a break. You have your opinion, I've got mine, whatever you think you are you're in no way an authority on the matter. There are many ways to implement an http router, there are also many ways to implement regular expressions. A bad implementation isn't saved by deeming the use of regexp "wrong tool for the job".

> A regex, while perfectly good for certain types of pattern matching makes no sense here.

What make no sense is your petty comment.

> Forget your pointless anti-go bias

Pointing out facts is "anti-go bias". OK , how about you stopping drinking the "pro-go koolaid" ?

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

#75
post #52

Earlier quoted context omitted.

All these routing libraries are just wrong level of abstraction. In HTTP you have resources, and resources are not flat, they are hierarchical. And hierarchy of resources defines some connection between then, and some common properties (data, access level etc). So any resource can respond to some HTTP method or can delegate to another, nested resource (if any) for any method. So (in PHP, from our still proprietary fr…

One downside I see to this: It's not possible to statically determine which resource will respond to which URL. I suppose that is also a benefit (maybe some resource can divert to another resource under heavy load/when its DB is unavailable). But quite frequently I want to answer this question with just the source code.

> But quite frequently I want to answer this question with just the source code.

Exactly. And that is also a benefit if routes are fetched dynamically from database, e.g. for content application, so your database is really content repository without too many levels of abstraction.

As for source code, it's kinda silly to split your app to fixed «controllers» and «models», you should split it functionally for simple reuse. Most modern PHP frameworks are so unflexible that way (laravel is just terrible IMO).

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

#76
post #59
post #52

Earlier quoted context omitted.

All these routing libraries are just wrong level of abstraction. In HTTP you have resources, and resources are not flat, they are hierarchical. And hierarchy of resources defines some connection between then, and some common properties (data, access level etc). So any resource can respond to some HTTP method or can delegate to another, nested resource (if any) for any method. So (in PHP, from our still proprietary fr…

> In HTTP you have resources, and resources are not flat, they are hierarchical. That isn't really true. There is nothing about HTTP, or even REST, that requires resources to be hierarchical. That said, it is quite common, and helpful for human beings, if they are hierarchical, so ... > I wonder why frameworks built this way are so uncommon Good question! The only one that springs to mind is Stapler: http://stapler.k…

There is Bullet http://bulletphp.com, that inspired us, but it is too simple and lacks some important (for us) features, e.g. recursion.

There are nested routes in Express and some Golang libraries (see gongular near on HN), but they are not resource oriented. And yes, there are resources in Rails, but it's sooo complex and heavy.

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

#77
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 ...

The comment linked is about CSV parsing being slow (the linked GitHub issue in the comment shows that the `regexp` doesn't show up in the benchmarks at all). So I don't understand why you linked a 6-year-old thread that's been revived by unrelated topics?

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

#78
post #72

Earlier quoted context omitted.

Because many of the base infrastructure libraries are compatible as long as they used interfaces ( grumble grumble os.File ). I would be very surprised if this doesn't implement net/http/ServeHTTP

It doesn't matter what it's named though, you can always alias the import. If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux. Import name similarity is a terrible argument for picking a name.

There are cases where it makes sense, like https://github.com/pkg/errors which is meant to be a drop-in replacement for the stdlib `errors` package containing a superset of its functionality.

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

#79
post #74
post #68

Earlier quoted context omitted.

FWIW If the router was in C or Rust or .net (which has a Jit for their regex engine) I would still tell you Regex is the wrong tool for splitting a URL on '/'. How many people have to tell you facts for you to believe them? Forget your pointless anti-go bias. A regex, while perfectly good for certain types of pattern matching makes no sense here. I often have taught the same lesson to my junior colleagues who use reg…

> How many people have to tell you facts for you to believe them? Forget your pointless anti-go bias Because a few people on HN is the consensus ? give me a break. You have your opinion, I've got mine, whatever you think you are you're in no way an authority on the matter. There are many ways to implement an http router, there are also many ways to implement regular expressions. A bad implementation isn't saved by de…

I think you're a bit delusional, I don't even write go (hence there literally being no koolaid for me to drink), but you're free to continue disagreeing, and continuing to be wrong :)

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

#80
post #73
post #71

Earlier quoted context omitted.

If you use a broken hammer to attempt to insert a screw, you're crazy for using the hammer, not because it's broken.

> If you use a broken hammer to attempt to insert a screw, you're crazy for using the hammer, not because it's broken. Are you resorting to insults now ? or is the typical hate and mean spirit of the Go community ? a router isn't a hammer. And I could care less about your opinion.

I sincerely did not intend to insult you. I'm also not associated with the go community.
Post reply on HN