61–70 of 80 posts
"In contrast to the default mux of Go's net/http package, this router supports variables in the routing pattern and matches against the request method. It also scales better."
What's the use case for all these routing libraries? Why not write a few lines of procedural code? It's a natural encoding of the routes "trie". @methods('POST') def set_int(request): x = pop_int_component(request) no_more_components(request) do_set_the_int(x) return Ok def myapp(request): x = pop_id_component(request) if x == 'set_int': return set_int(request) else: return NotFound No type system hacks, extremely mo…
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…
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.
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 ...
You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp.
Avoiding regexp doesn't fix Go's implementation of regexp. Making them faster does. Your argument is preposterous. If the Go team really cared about performances it would fix its regexp implementation.
Earlier quoted context omitted.
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.
That said, most regex performance problems are PEBKAC. Writing a fast regex is hard and requires a pretty thorough understanding of parser theory. And many who use regexes don't understand that it's critical to precompile them for performance. You don't get a fast parser when you rebuild the DFA each time you use it.
*edit: a word
Earlier quoted context omitted.
You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp.
> You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp. Avoiding regexp doesn't fix Go's implementation of regexp. Making them faster does. Your argument is preposterous. If the Go team reall…
Earlier quoted context omitted.
> You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp. Avoiding regexp doesn't fix Go's implementation of regexp. Making them faster does. Your argument is preposterous. If the Go team reall…
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 the job. And deeming it the wrong tool for the job doesn't fix Go regex being slower than in other languages. The 2 issues are not separate .People like you talk about performances as a goal while dismissing obviously performance issues in the standard library as "wrong tool for the job".
You're not going to convince anybody with this kind of argument, aside from gophers who already think like you do. I'm not one of them.
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?
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…
I often have taught the same lesson to my junior colleagues who use regex in Python or C++ code where splitting the string would be simpler, more maintainable, and faster.
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…
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…
These links are pretty cool. Are there any tutorials or walkthroughs you would recommend? Like, Go has always interested me but I have no idea where to start to get an experience like say ExpressJS or even where to find templating or rendering. Any suggestions are appreciated!
I have written a very basic introduction to writing webapps in Go without using a framework, as others have rightly pointed out, we really do not need to use a framework in Go for writing webapps, and Go is a great language.
If you don't like mine, https://github.com/astaxie/build-web-application-with-golang... is a nice start for new comers.