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…
Mux – A lightweight, fast HTTP request router for Go
71–80 of 80 posts
Re: Mux – A lightweight, fast HTTP request router for Go
#72Earlier 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
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
#73Earlier 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.
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
#74Earlier 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…
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
#75Earlier 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.
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
#76Earlier 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 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
#77Earlier 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 ...
Re: Mux – A lightweight, fast HTTP request router for Go
#78Earlier 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.
Re: Mux – A lightweight, fast HTTP request router for Go
#79Earlier 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…
Re: Mux – A lightweight, fast HTTP request router for Go
#80Earlier 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.