FAQ
I'm trying to port a large Ruby Sinatra based web app to Go. Love the
language so far (albeit, the lack of macros, generics, overloading, real
classes, ternary conditions, string interpolation to name a few are rather
cumbersome once you've had them all in other languages) but the standard
library and performance alone make up for the rest (for now :D). But the
one thing that bothers me with the task at hand is http.HandlFunc won't do
regexes! Nor is there some way to hook into before/after request handling.
Is there any chance this might be added to the library? Thanks!

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • David Symonds at May 23, 2013 at 8:57 pm
    No, but lots of folk use http://www.gorillatoolkit.org/pkg/mux to get that.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 2:05 am
    Oh. Why not? Btw, does the Go team allow patching/contributing to the
    library? If so, I'd like to explore adding this to the lib myself!

    I guess I could use Gorilla for now but the lack of anything remotely
    complicated not making into the language/library is tiring.
    On Thursday, May 23, 2013 4:57:12 PM UTC-4, David Symonds wrote:

    No, but lots of folk use http://www.gorillatoolkit.org/pkg/mux to get
    that.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at May 24, 2013 at 2:08 am

    On Fri, May 24, 2013 at 7:40 AM, wrote:

    Oh. Why not? Btw, does the Go team allow patching/contributing to the
    library? If so, I'd like to explore adding this to the lib myself!

    I guess I could use Gorilla for now but the lack of anything remotely
    complicated not making into the language/library is tiring.
    net/http being in the standard library is a basis for arbitrary HTTP
    clients and servers, and is supported as part of the Go 1
    compatibility guarantee. There's no need to add extra complexity such
    as regexp-based routing since it is so easy to build that as a
    separate package (e.g. what gorilla does), and because everyone will
    want something slightly different. Many, many Go servers have no need
    for regexp routing, so it is not as critical a feature as you may
    think.

    Go's lack of complexity is a feature, not a bug.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 4:34 am
    I get what you're saying but just because many many servers don't need a
    feature doesn't mean many many others don't as well. Also just because
    everyone will want it slightly different doesn't mean there can't be a
    reference solution. I guess all I'm saying is, I think keeping complexity
    away from the language is a good thing, a small language is easy to learn
    and maintain but I'm sure you'll agree no one will say no to an extensive
    well thought out library. But then again, may be I'm just spoiled by Ruby.

    On Thursday, May 23, 2013 10:08:43 PM UTC-4, David Symonds wrote:

    On Fri, May 24, 2013 at 7:40 AM, <ace....@gmail.com <javascript:>>
    wrote:
    Oh. Why not? Btw, does the Go team allow patching/contributing to the
    library? If so, I'd like to explore adding this to the lib myself!

    I guess I could use Gorilla for now but the lack of anything remotely
    complicated not making into the language/library is tiring.
    net/http being in the standard library is a basis for arbitrary HTTP
    clients and servers, and is supported as part of the Go 1
    compatibility guarantee. There's no need to add extra complexity such
    as regexp-based routing since it is so easy to build that as a
    separate package (e.g. what gorilla does), and because everyone will
    want something slightly different. Many, many Go servers have no need
    for regexp routing, so it is not as critical a feature as you may
    think.

    Go's lack of complexity is a feature, not a bug.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at May 24, 2013 at 4:38 am

    On Fri, May 24, 2013 at 12:42 PM, wrote:

    I get what you're saying but just because many many servers don't need a
    feature doesn't mean many many others don't as well. Also just because
    everyone will want it slightly different doesn't mean there can't be a
    reference solution. I guess all I'm saying is, I think keeping complexity
    away from the language is a good thing, a small language is easy to learn
    and maintain but I'm sure you'll agree no one will say no to an extensive
    well thought out library. But then again, may be I'm just spoiled by Ruby.
    Go has some great development tools ("go get" and its friends) that
    make using third-party packages almost as easy as using standard
    library packages. We did it that way for this reason: so stuff doesn't
    need to be in the standard library for people to use it easily.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at May 24, 2013 at 5:46 am

    On 24 May 2013 12:42, wrote:

    But then again, may be I'm just spoiled by Ruby.

    Correct me if I'm wrong, but I don't think the regexp pattern matcher that
    you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could make
    add a more complex pattern matcher to the standard mux, but then that's
    something we have to support forever—regardless of the number of people
    using it. I know that both Gorilla's mux and bmizerany/pat are
    well-maintained projects that you can depend on. There's no need to be
    afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 3:58 pm
    You are correct, the regex matcher is part of a framework called Sinatra.
    But that alone is not my point. Regex is a first class citizen in Ruby and
    anywhere in the stdlib functions a string is expected you could pass a
    regex.

    With that said, I do hate parts of Ruby. Dependency hell comes to mind. And
    cross compilation is a real pain in the neck when it comes to gems. Things
    just flat out don't work if you're on Windows. Which is why I want my
    affair with Go to work out! :D

    On Friday, May 24, 2013 1:46:24 AM UTC-4, Andrew Gerrand wrote:
    On 24 May 2013 12:42, <ace....@gmail.com <javascript:>> wrote:

    But then again, may be I'm just spoiled by Ruby.

    Correct me if I'm wrong, but I don't think the regexp pattern matcher that
    you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could make
    add a more complex pattern matcher to the standard mux, but then that's
    something we have to support forever—regardless of the number of people
    using it. I know that both Gorilla's mux and bmizerany/pat are
    well-maintained projects that you can depend on. There's no need to be
    afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Niklas Schnelle at May 24, 2013 at 6:15 pm
    You are missing the point of a standard library. It's not about providing
    all features, it's about providing enabling features. Of course the border
    line is drawn arbitary but it's drawn by informed people that try to keep
    all of the ecosystem in mind. So what they are trying to add are things
    that have an unusual benefit as ground breakers or in enabling things.
    As I'm not affiliated with the project contributers I can only assume but
    let me still guess for a few examples why they are in the standard library:
    - Crypto because it is really hard to get right and enables stuff like TLS
    connections
    - Container because everyone needs them
    - Net because it needs to integrate with the runtime and we need platform
    abstraction there
    - Http because it's the basis of the modern web and of outmost importance
    with an Api designed to be both maintainable
    while still covering the really hard part like correctly and efficiently
    parsing HTTP.
    - Compression because it's hard and enables HTTP
    I could go on but maybe you get why these are really different from "I want
    to route based on X" the HTTP package enables the community to do that
    for pretty much every X and also to make it easy for others to use those X
    that are common. Tell me one reason why it would be better to have
    regex routing in the standard library than in gorilla?
    On Friday, May 24, 2013 4:25:04 PM UTC+2, ace....@gmail.com wrote:

    You are correct, the regex matcher is part of a framework called Sinatra.
    But that alone is not my point. Regex is a first class citizen in Ruby and
    anywhere in the stdlib functions a string is expected you could pass a
    regex.

    With that said, I do hate parts of Ruby. Dependency hell comes to mind.
    And cross compilation is a real pain in the neck when it comes to gems.
    Things just flat out don't work if you're on Windows. Which is why I want
    my affair with Go to work out! :D

    On Friday, May 24, 2013 1:46:24 AM UTC-4, Andrew Gerrand wrote:
    On 24 May 2013 12:42, wrote:

    But then again, may be I'm just spoiled by Ruby.

    Correct me if I'm wrong, but I don't think the regexp pattern matcher
    that you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could
    make add a more complex pattern matcher to the standard mux, but then
    that's something we have to support forever—regardless of the number of
    people using it. I know that both Gorilla's mux and bmizerany/pat are
    well-maintained projects that you can depend on. There's no need to be
    afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 7:07 pm
    And that's fine -- enabling features. One must start somewhere but then
    it's only natural to cover more ground. But as you rightly mentioned the
    arbitrary lines are the problem.

    I can think of a few reasons (Carlos, above, seems to mention one I didn't
    know) --

    - Don't have the link at the moment but I heard about a project that was
    abandoned as it wouldn't compile anymore due to some dependencies that
    changed underneath (read it on HN I think)
    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting stdlib
    idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long
    query parameters even on this very site (don't know if it's on net/http).
    Same with golang.org (which I know is running on net/http). Which means
    doing any sort of before/after hooks is painful due to code duplication in
    every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when
    their build fails.


    It's my opinion that people chose to migrate to other languages not purely
    influenced by the language itself but by the underlying stdlib as well. And
    having an extensive library never hurt anyone.



    On Friday, May 24, 2013 2:15:40 PM UTC-4, Niklas Schnelle wrote:

    You are missing the point of a standard library. It's not about providing
    all features, it's about providing enabling features. Of course the border
    line is drawn arbitary but it's drawn by informed people that try to keep
    all of the ecosystem in mind. So what they are trying to add are things
    that have an unusual benefit as ground breakers or in enabling things.
    As I'm not affiliated with the project contributers I can only assume but
    let me still guess for a few examples why they are in the standard library:
    - Crypto because it is really hard to get right and enables stuff like TLS
    connections
    - Container because everyone needs them
    - Net because it needs to integrate with the runtime and we need platform
    abstraction there
    - Http because it's the basis of the modern web and of outmost importance
    with an Api designed to be both maintainable
    while still covering the really hard part like correctly and efficiently
    parsing HTTP.
    - Compression because it's hard and enables HTTP
    I could go on but maybe you get why these are really different from "I
    want to route based on X" the HTTP package enables the community to do that
    for pretty much every X and also to make it easy for others to use those X
    that are common. Tell me one reason why it would be better to have
    regex routing in the standard library than in gorilla?
    On Friday, May 24, 2013 4:25:04 PM UTC+2, ace....@gmail.com wrote:

    You are correct, the regex matcher is part of a framework called Sinatra.
    But that alone is not my point. Regex is a first class citizen in Ruby and
    anywhere in the stdlib functions a string is expected you could pass a
    regex.

    With that said, I do hate parts of Ruby. Dependency hell comes to mind.
    And cross compilation is a real pain in the neck when it comes to gems.
    Things just flat out don't work if you're on Windows. Which is why I want
    my affair with Go to work out! :D

    On Friday, May 24, 2013 1:46:24 AM UTC-4, Andrew Gerrand wrote:
    On 24 May 2013 12:42, wrote:

    But then again, may be I'm just spoiled by Ruby.

    Correct me if I'm wrong, but I don't think the regexp pattern matcher
    that you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could
    make add a more complex pattern matcher to the standard mux, but then
    that's something we have to support forever—regardless of the number of
    people using it. I know that both Gorilla's mux and bmizerany/pat are
    well-maintained projects that you can depend on. There's no need to be
    afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ryan Leavengood at May 24, 2013 at 10:54 pm

    On Friday, May 24, 2013 3:07:50 PM UTC-4, ace....@gmail.com wrote:

    And that's fine -- enabling features. One must start somewhere but then
    it's only natural to cover more ground. But as you rightly mentioned the
    arbitrary lines are the problem.

    I'm a fellow Ruby programmer who has also been quite pleased with Go. As
    for the topic at hand, I agree with everyone that the place for a complex
    request muxer is out of the standard library. You really should understand
    that the Gorilla project is very well respected and nicely maintained, to
    the point of almost being like part of the standard library. Read through
    these excellent blog posts to see how stupidly easy it is to add Gorilla's
    pat muxer to an existing net/http project:

    http://shadynasty.biz/blog/2012/07/30/quick-and-clean-in-go/
    http://shadynasty.biz/blog/2012/08/07/painless-web-handlers-in-go/

    I can think of a few reasons (Carlos, above, seems to mention one I didn't
    know) --

    - Don't have the link at the moment but I heard about a project that was
    abandoned as it wouldn't compile anymore due to some dependencies that
    changed underneath (read it on HN I think)
    That was Haunts, and if you dig into the history of the project, I think
    they had a lot more problems than bad Go dependency management. Also
    blaming Go for their bad decisions and bad coding practices was a cop-out.
    The thread on thedailywtf.com about this is just full of ignorant people
    saying how "this stupid language called Go which they never heard of and
    which nobody probably uses is what made Haunts fail." When in reality, it
    seems Haunts had newbie programmers who did not know how to properly manage
    dependencies and got in over their heads on an overly complex project for
    their skill levels. And the dependency issues were all around OpenGL, which
    depends on cgo, which is known to be problematic at times (which is why
    pure Go implementations of packages are generally preferred.)

    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting stdlib
    idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long
    query parameters even on this very site (don't know if it's on net/http).
    Same with golang.org (which I know is running on net/http). Which means
    doing any sort of before/after hooks is painful due to code duplication in
    every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when
    their build fails.
    Yes these are all valid reasons why external dependencies can be a problem.
    But surely you don't think every RubyGem in existence should be folded into
    the Ruby standard library???

    Also consider that Go and the Go community and ecosystem is relatively
    young. Over time certain developers, companies and projects will become
    well known for producing quality Go packages. Also certain packages will
    become known as the best in that area, based on being well written and well
    maintained. If I want to talk to Mongo in Go, I would use
    http://labix.org/mgo. If I want to talk to MySQL, I would
    use https://github.com/go-sql-driver/mysql. It didn't take me long to
    figure out that those were some of the better packages for those tasks.

    It's my opinion that people chose to migrate to other languages not purely
    influenced by the language itself but by the underlying stdlib as well. And
    having an extensive library never hurt anyone.
    Yes it can be hurtful. There is a bunch of cruft and crap shipped with Ruby
    that no one ever uses because it was added to the Ruby standard library
    years ago and so now can pretty much never be removed. It actually makes
    much more sense to keep a standard library lean and mean but make it easy
    to add external dependencies. I think Go does that pretty well.

    Regards,
    Ryan

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 25, 2013 at 12:17 am
    Good to hear from another Ruby programmer. I'm loving Go too if you can't
    tell already. I'm sorry you think there's lot of cruft in the Ruby stdlib.
    But here's the thing, no one quit Ruby/or any other language for that
    matter because there were too many functions in the stdlib.

    And I was aware that it was only a matter of time before someone came up
    with the "well then, let's merge everything into the stdlib". Certain
    usecases belong together whether one likes it or not. Url parsing with
    string/regex happens to be one.

    On Friday, May 24, 2013 6:54:53 PM UTC-4, Ryan Leavengood wrote:
    On Friday, May 24, 2013 3:07:50 PM UTC-4, ace....@gmail.com wrote:

    And that's fine -- enabling features. One must start somewhere but then
    it's only natural to cover more ground. But as you rightly mentioned the
    arbitrary lines are the problem.

    I'm a fellow Ruby programmer who has also been quite pleased with Go. As
    for the topic at hand, I agree with everyone that the place for a complex
    request muxer is out of the standard library. You really should understand
    that the Gorilla project is very well respected and nicely maintained, to
    the point of almost being like part of the standard library. Read through
    these excellent blog posts to see how stupidly easy it is to add Gorilla's
    pat muxer to an existing net/http project:

    http://shadynasty.biz/blog/2012/07/30/quick-and-clean-in-go/
    http://shadynasty.biz/blog/2012/08/07/painless-web-handlers-in-go/

    I can think of a few reasons (Carlos, above, seems to mention one I
    didn't know) --

    - Don't have the link at the moment but I heard about a project that was
    abandoned as it wouldn't compile anymore due to some dependencies that
    changed underneath (read it on HN I think)
    That was Haunts, and if you dig into the history of the project, I think
    they had a lot more problems than bad Go dependency management. Also
    blaming Go for their bad decisions and bad coding practices was a cop-out.
    The thread on thedailywtf.com about this is just full of ignorant people
    saying how "this stupid language called Go which they never heard of and
    which nobody probably uses is what made Haunts fail." When in reality, it
    seems Haunts had newbie programmers who did not know how to properly manage
    dependencies and got in over their heads on an overly complex project for
    their skill levels. And the dependency issues were all around OpenGL, which
    depends on cgo, which is known to be problematic at times (which is why
    pure Go implementations of packages are generally preferred.)

    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting stdlib
    idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long
    query parameters even on this very site (don't know if it's on net/http).
    Same with golang.org (which I know is running on net/http). Which means
    doing any sort of before/after hooks is painful due to code duplication in
    every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when
    their build fails.
    Yes these are all valid reasons why external dependencies can be a
    problem. But surely you don't think every RubyGem in existence should be
    folded into the Ruby standard library???

    Also consider that Go and the Go community and ecosystem is relatively
    young. Over time certain developers, companies and projects will become
    well known for producing quality Go packages. Also certain packages will
    become known as the best in that area, based on being well written and well
    maintained. If I want to talk to Mongo in Go, I would use
    http://labix.org/mgo. If I want to talk to MySQL, I would use
    https://github.com/go-sql-driver/mysql. It didn't take me long to figure
    out that those were some of the better packages for those tasks.

    It's my opinion that people chose to migrate to other languages not
    purely influenced by the language itself but by the underlying stdlib as
    well. And having an extensive library never hurt anyone.
    Yes it can be hurtful. There is a bunch of cruft and crap shipped with
    Ruby that no one ever uses because it was added to the Ruby standard
    library years ago and so now can pretty much never be removed. It actually
    makes much more sense to keep a standard library lean and mean but make it
    easy to add external dependencies. I think Go does that pretty well.

    Regards,
    Ryan
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at May 25, 2013 at 1:21 am

    On Fri, May 24, 2013 at 5:16 PM, wrote:

    Good to hear from another Ruby programmer. I'm loving Go too if you can't
    tell already. I'm sorry you think there's lot of cruft in the Ruby stdlib.
    But here's the thing, no one quit Ruby/or any other language for that
    matter because there were too many functions in the stdlib.

    And I was aware that it was only a matter of time before someone came up
    with the "well then, let's merge everything into the stdlib". Certain
    usecases belong together whether one likes it or not. Url parsing with
    string/regex happens to be one.
    I happen to be of the opposite opinion. I've long thought that regex in
    routing is overkill for a vast majority of cases, if not all. I've yet to
    have the desire to use them in any of the many webapps I've created.

    Also, regex is slower than standard string comparison, sometimes by a
    pretty substantial amount. It wouldn't surprise me if Go's ServeMux ends
    up being backed by a trie at some point as well. I think one could
    probably construct a regex matcher in such a way that it simultaneously
    matched all patterns against the input, but that seems like it would be be
    an incredibly specialized piece of code and more likely to show up in a
    third party library than in the stdlib.
    On Friday, May 24, 2013 6:54:53 PM UTC-4, Ryan Leavengood wrote:
    On Friday, May 24, 2013 3:07:50 PM UTC-4, ace....@gmail.com wrote:

    And that's fine -- enabling features. One must start somewhere but then
    it's only natural to cover more ground. But as you rightly mentioned the
    arbitrary lines are the problem.

    I'm a fellow Ruby programmer who has also been quite pleased with Go. As
    for the topic at hand, I agree with everyone that the place for a complex
    request muxer is out of the standard library. You really should understand
    that the Gorilla project is very well respected and nicely maintained, to
    the point of almost being like part of the standard library. Read through
    these excellent blog posts to see how stupidly easy it is to add Gorilla's
    pat muxer to an existing net/http project:

    http://shadynasty.biz/blog/**2012/07/30/quick-and-clean-in-**go/<http://shadynasty.biz/blog/2012/07/30/quick-and-clean-in-go/>
    http://shadynasty.biz/blog/**2012/08/07/painless-web-**handlers-in-go/<http://shadynasty.biz/blog/2012/08/07/painless-web-handlers-in-go/>

    I can think of a few reasons (Carlos, above, seems to mention one I
    didn't know) --

    - Don't have the link at the moment but I heard about a project that was
    abandoned as it wouldn't compile anymore due to some dependencies that
    changed underneath (read it on HN I think)
    That was Haunts, and if you dig into the history of the project, I think
    they had a lot more problems than bad Go dependency management. Also
    blaming Go for their bad decisions and bad coding practices was a cop-out.
    The thread on thedailywtf.com about this is just full of ignorant people
    saying how "this stupid language called Go which they never heard of and
    which nobody probably uses is what made Haunts fail." When in reality, it
    seems Haunts had newbie programmers who did not know how to properly manage
    dependencies and got in over their heads on an overly complex project for
    their skill levels. And the dependency issues were all around OpenGL, which
    depends on cgo, which is known to be problematic at times (which is why
    pure Go implementations of packages are generally preferred.)

    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting
    stdlib idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long
    query parameters even on this very site (don't know if it's on net/http).
    Same with golang.org (which I know is running on net/http). Which means
    doing any sort of before/after hooks is painful due to code duplication in
    every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when
    their build fails.
    Yes these are all valid reasons why external dependencies can be a
    problem. But surely you don't think every RubyGem in existence should be
    folded into the Ruby standard library???

    Also consider that Go and the Go community and ecosystem is relatively
    young. Over time certain developers, companies and projects will become
    well known for producing quality Go packages. Also certain packages will
    become known as the best in that area, based on being well written and well
    maintained. If I want to talk to Mongo in Go, I would use
    http://labix.org/mgo. If I want to talk to MySQL, I would use
    https://github.com/go-sql-**driver/mysql<https://github.com/go-sql-driver/mysql>.
    It didn't take me long to figure out that those were some of the better
    packages for those tasks.

    It's my opinion that people chose to migrate to other languages not
    purely influenced by the language itself but by the underlying stdlib as
    well. And having an extensive library never hurt anyone.
    Yes it can be hurtful. There is a bunch of cruft and crap shipped with
    Ruby that no one ever uses because it was added to the Ruby standard
    library years ago and so now can pretty much never be removed. It actually
    makes much more sense to keep a standard library lean and mean but make it
    easy to add external dependencies. I think Go does that pretty well.

    Regards,
    Ryan
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sanjay at May 25, 2013 at 2:30 am
    I think one could probably construct a regex matcher in such a way that
    it simultaneously matched all patterns against the input, but that seems
    like it would be be an incredibly specialized piece of code and more likely
    to show up in a third party library than in the stdlib.

    I've actually had this same thought previously, but thought that it
    probably wasn't worth doing because you wouldn't get the benefits from any
    improvements in the standard library's code.

    Sanjay

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at May 24, 2013 at 11:28 pm
    Ok, now it is clear. You would like regex routes to be included in the std library because you do not want an external dependency or are concerned that those dependencies are going to be brittle. If this is the case then this is an issue that is front and center for most readers of this news group and various solutions for dependency management are appearing.

    On 25/05/2013, at 5:07, ace.rajan@gmail.com wrote:

    And that's fine -- enabling features. One must start somewhere but then it's only natural to cover more ground. But as you rightly mentioned the arbitrary lines are the problem.

    I can think of a few reasons (Carlos, above, seems to mention one I didn't know) --

    - Don't have the link at the moment but I heard about a project that was abandoned as it wouldn't compile anymore due to some dependencies that changed underneath (read it on HN I think)
    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting stdlib idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long query parameters even on this very site (don't know if it's on net/http). Same with golang.org (which I know is running on net/http). Which means doing any sort of before/after hooks is painful due to code duplication in every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when their build fails.


    It's my opinion that people chose to migrate to other languages not purely influenced by the language itself but by the underlying stdlib as well. And having an extensive library never hurt anyone.



    On Friday, May 24, 2013 2:15:40 PM UTC-4, Niklas Schnelle wrote:

    You are missing the point of a standard library. It's not about providing all features, it's about providing enabling features. Of course the border line is drawn arbitary but it's drawn by informed people that try to keep all of the ecosystem in mind. So what they are trying to add are things that have an unusual benefit as ground breakers or in enabling things.
    As I'm not affiliated with the project contributers I can only assume but let me still guess for a few examples why they are in the standard library:
    - Crypto because it is really hard to get right and enables stuff like TLS connections
    - Container because everyone needs them
    - Net because it needs to integrate with the runtime and we need platform abstraction there
    - Http because it's the basis of the modern web and of outmost importance with an Api designed to be both maintainable
    while still covering the really hard part like correctly and efficiently parsing HTTP.
    - Compression because it's hard and enables HTTP
    I could go on but maybe you get why these are really different from "I want to route based on X" the HTTP package enables the community to do that
    for pretty much every X and also to make it easy for others to use those X that are common. Tell me one reason why it would be better to have
    regex routing in the standard library than in gorilla?
    On Friday, May 24, 2013 4:25:04 PM UTC+2, ace....@gmail.com wrote:

    You are correct, the regex matcher is part of a framework called Sinatra. But that alone is not my point. Regex is a first class citizen in Ruby and anywhere in the stdlib functions a string is expected you could pass a regex.

    With that said, I do hate parts of Ruby. Dependency hell comes to mind. And cross compilation is a real pain in the neck when it comes to gems. Things just flat out don't work if you're on Windows. Which is why I want my affair with Go to work out! :D

    On Friday, May 24, 2013 1:46:24 AM UTC-4, Andrew Gerrand wrote:
    On 24 May 2013 12:42, wrote:
    But then again, may be I'm just spoiled by Ruby.
    Correct me if I'm wrong, but I don't think the regexp pattern matcher that you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could make add a more complex pattern matcher to the standard mux, but then that's something we have to support forever—regardless of the number of people using it. I know that both Gorilla's mux and bmizerany/pat are well-maintained projects that you can depend on. There's no need to be afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 25, 2013 at 12:13 am
    Nope. That may be what I'm saying indirectly but my primary point is that
    string and regex matchers belong together and deserve to be packaged
    together.
    On Friday, May 24, 2013 7:28:24 PM UTC-4, Dave Cheney wrote:

    Ok, now it is clear. You would like regex routes to be included in the std
    library because you do not want an external dependency or are concerned
    that those dependencies are going to be brittle. If this is the case then
    this is an issue that is front and center for most readers of this news
    group and various solutions for dependency management are appearing.


    On 25/05/2013, at 5:07, ace....@gmail.com <javascript:> wrote:

    And that's fine -- enabling features. One must start somewhere but then
    it's only natural to cover more ground. But as you rightly mentioned the
    arbitrary lines are the problem.

    I can think of a few reasons (Carlos, above, seems to mention one I didn't
    know) --

    - Don't have the link at the moment but I heard about a project that was
    abandoned as it wouldn't compile anymore due to some dependencies that
    changed underneath (read it on HN I think)
    - It's hard to keep track of various projects and their limitations
    - There may not be enough documentation
    - You never know when they will be abandoned by their owners
    - The custom api might be drastically different from the exisiting stdlib
    idioms
    - Bug fixes may not come in a timely fashion
    - Security issues may be overlooked due to lack of time/interest/insight
    - It's only natural to prefer clean urls. I don't see any utterly long
    query parameters even on this very site (don't know if it's on net/http).
    Same with golang.org (which I know is running on net/http). Which means
    doing any sort of before/after hooks is painful due to code duplication in
    every HandleFunc()
    - Many people abhor additional dependencies. Those who don't, will, when
    their build fails.


    It's my opinion that people chose to migrate to other languages not purely
    influenced by the language itself but by the underlying stdlib as well. And
    having an extensive library never hurt anyone.



    On Friday, May 24, 2013 2:15:40 PM UTC-4, Niklas Schnelle wrote:

    You are missing the point of a standard library. It's not about providing
    all features, it's about providing enabling features. Of course the border
    line is drawn arbitary but it's drawn by informed people that try to keep
    all of the ecosystem in mind. So what they are trying to add are things
    that have an unusual benefit as ground breakers or in enabling things.
    As I'm not affiliated with the project contributers I can only assume but
    let me still guess for a few examples why they are in the standard library:
    - Crypto because it is really hard to get right and enables stuff like
    TLS connections
    - Container because everyone needs them
    - Net because it needs to integrate with the runtime and we need platform
    abstraction there
    - Http because it's the basis of the modern web and of outmost importance
    with an Api designed to be both maintainable
    while still covering the really hard part like correctly and efficiently
    parsing HTTP.
    - Compression because it's hard and enables HTTP
    I could go on but maybe you get why these are really different from "I
    want to route based on X" the HTTP package enables the community to do that
    for pretty much every X and also to make it easy for others to use those
    X that are common. Tell me one reason why it would be better to have
    regex routing in the standard library than in gorilla?
    On Friday, May 24, 2013 4:25:04 PM UTC+2, ace....@gmail.com wrote:

    You are correct, the regex matcher is part of a framework called
    Sinatra. But that alone is not my point. Regex is a first class citizen in
    Ruby and anywhere in the stdlib functions a string is expected you could
    pass a regex.

    With that said, I do hate parts of Ruby. Dependency hell comes to mind.
    And cross compilation is a real pain in the neck when it comes to gems.
    Things just flat out don't work if you're on Windows. Which is why I want
    my affair with Go to work out! :D

    On Friday, May 24, 2013 1:46:24 AM UTC-4, Andrew Gerrand wrote:
    On 24 May 2013 12:42, wrote:

    But then again, may be I'm just spoiled by Ruby.

    Correct me if I'm wrong, but I don't think the regexp pattern matcher
    that you're used to is part of the Ruby standard library.

    Go has a great standard library, but it also has its limits. We could
    make add a more complex pattern matcher to the standard mux, but then
    that's something we have to support forever—regardless of the number of
    people using it. I know that both Gorilla's mux and bmizerany/pat are
    well-maintained projects that you can depend on. There's no need to be
    afraid of a couple of external dependencies—they're just a "go get" away.

    Andrew
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at May 24, 2013 at 12:40 am

    On Fri, May 24, 2013 at 6:49 AM, wrote:

    I'm trying to port a large Ruby Sinatra based web app to Go.

    You might like 'pat' from the people that brought you 'sinatra'
    https://github.com/bmizerany/pat

    Love the language so far (albeit, the lack of macros, generics,
    overloading, real classes, ternary conditions, string interpolation to name
    a few are rather cumbersome once you've had them all in other languages)
    but the standard library and performance alone make up for the rest (for
    now :D).

    You're listing many of my favourite parts of Go.

    But the one thing that bothers me with the task at hand is http.HandlFunc
    won't do regexes! Nor is there some way to hook into before/after request
    handling. Is there any chance this might be added to the library?

    The standard http package is a lot more like 'rack' than like 'sinatra'.



    --
    =====================
    http://jessta.id.au

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 2:05 am
    I concur the http package is akin to Rack but I don't see any reason why a
    few helper methods for such a common case can't be included in the package
    given that there is support for regex already (granted not as first class
    citizens, but still). I'm not an expert in Go but I'm willing to explore
    the idea of submitting a patch if that's what it takes.

    And thanks, I didn't know about Pat, will check it out.

    On Thursday, May 23, 2013 8:40:21 PM UTC-4, Jesse McNelis wrote:
    On Fri, May 24, 2013 at 6:49 AM, <ace....@gmail.com <javascript:>> wrote:

    I'm trying to port a large Ruby Sinatra based web app to Go.

    You might like 'pat' from the people that brought you 'sinatra'
    https://github.com/bmizerany/pat

    Love the language so far (albeit, the lack of macros, generics,
    overloading, real classes, ternary conditions, string interpolation to name
    a few are rather cumbersome once you've had them all in other languages)
    but the standard library and performance alone make up for the rest (for
    now :D).

    You're listing many of my favourite parts of Go.

    But the one thing that bothers me with the task at hand is http.HandlFunc
    won't do regexes! Nor is there some way to hook into before/after request
    handling. Is there any chance this might be added to the library?

    The standard http package is a lot more like 'rack' than like 'sinatra'.



    --
    =====================
    http://jessta.id.au
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Cobo at May 24, 2013 at 6:08 pm
    pat (and gorilla/mux) have some issues with path preference, they just work according to creation order, unlike http.ServeMux.

    Some time ago I did this to have pat-like routes but keeping preference:
    https://github.com/toqueteos/web/pat

    It's easy to modify it and allow regexes.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 6:36 pm
    link 404s
    On Friday, May 24, 2013 2:08:54 PM UTC-4, Carlos Cobo wrote:

    pat (and gorilla/mux) have some issues with path preference, they just
    work according to creation order, unlike http.ServeMux.

    Some time ago I did this to have pat-like routes but keeping preference:
    https://github.com/toqueteos/web/pat

    It's easy to modify it and allow regexes.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Cobo at May 27, 2013 at 3:24 pm
    That was the go-gettable/godoc.org link. Obviously it 404s because github
    needs full URLs like this https://github.com/toqueteos/web/tree/master/pat if
    you want subfolders.

    El viernes, 24 de mayo de 2013 20:36:44 UTC+2, ace....@gmail.com escribió:
    link 404s
    On Friday, May 24, 2013 2:08:54 PM UTC-4, Carlos Cobo wrote:

    pat (and gorilla/mux) have some issues with path preference, they just
    work according to creation order, unlike http.ServeMux.

    Some time ago I did this to have pat-like routes but keeping preference:
    https://github.com/toqueteos/web/pat

    It's easy to modify it and allow regexes.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Johnstone at May 24, 2013 at 2:53 am
    Hello,

    With regards to matching a handler with a regex, the only package that I'm
    aware of that takes this approach is mine. Please check out
    https://bitbucket.org/rj/httprouter-go. I don't think the code should be
    considered production ready, but it is designed to provide the type of
    behaviour that you desire.

    With regards to before/after request handling, there are a couple of
    different approaches. One approach, which is what I typically use, is to
    chain the requests. Use either a struct that implements the handler
    interface or a closure to, for example, perform authentication, which if
    successful then calls another handler to implement the request.

    If you really want pre and post hooks, I would suggest creating a simple
    type that implements the desired functionality.

    The standard lib does only provide a relatively basic starting point. I
    believe the community is still iterating towards on the design of more
    complete frameworks.

    Good luck.
    On Thursday, 23 May 2013 20:49:08 UTC, ace....@gmail.com wrote:

    I'm trying to port a large Ruby Sinatra based web app to Go. Love the
    language so far (albeit, the lack of macros, generics, overloading, real
    classes, ternary conditions, string interpolation to name a few are rather
    cumbersome once you've had them all in other languages) but the standard
    library and performance alone make up for the rest (for now :D). But the
    one thing that bothers me with the task at hand is http.HandlFunc won't do
    regexes! Nor is there some way to hook into before/after request handling.
    Is there any chance this might be added to the library? Thanks!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Silverlock at May 24, 2013 at 11:51 am
    http://www.gorillatoolkit.org/pkg/mux and http://www.gorillatoolkit.org/pkg/pat are both so incredibly simple to integrate with net/http that replicating their functionality in the standard library is only going to add to the weight needed each release.

    I can understand the OP's desire to have them included, but including everything that "might" be useful to "many" is a dangerous road (where do you say no?).

    Each block of functionality you add to the standard library is just more work to look after each release cycle.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ace Rajan at May 24, 2013 at 3:58 pm
    But couldn't the same be said of everything? Why add a templating
    (text/html/template) package when community will pitch in with a solution.
    Why add a FileServer handler when Apache/Nginx will suffice. I could go on.

    Isn't it better to have a standard implementation that covers a majority of
    usecases than let people iterate and come up scores of implementations only
    to abandon them without care?

    Does it add more work to maintain? Yes. But isn't the whole purpose of a
    language/library/framework to shift the burden from programmer to the tools?

    On Friday, May 24, 2013 7:50:58 AM UTC-4, Matt Silverlock wrote:

    http://www.gorillatoolkit.org/pkg/mux and
    http://www.gorillatoolkit.org/pkg/pat are both so incredibly simple to
    integrate with net/http that replicating their functionality in the
    standard library is only going to add to the weight needed each release.

    I can understand the OP's desire to have them included, but including
    everything that "might" be useful to "many" is a dangerous road (where do
    you say no?).

    Each block of functionality you add to the standard library is just more
    work to look after each release cycle.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at May 24, 2013 at 6:14 pm

    On Fri, May 24, 2013 at 7:16 AM, wrote:

    But couldn't the same be said of everything? Why add a templating
    (text/html/template) package when community will pitch in with a solution.
    Why add a FileServer handler when Apache/Nginx will suffice. I could go on.

    Autoescaping is very hard. It makes sense to do it right once.
      ServeFile/ServeContent is also hard, when you take into account things
    like ETag and If-Modified-Since, etc. A lot of these are also used for the
    Go website (godoc), which is in the standard distro, and only has
    dependencies within the stdlib.

    Isn't it better to have a standard implementation that covers a majority
    of usecases than let people iterate and come up scores of implementations
    only to abandon them without care?
    Keep it simple. net/http is easy to understand, and it's hard to argue
    with what it gives you. Pattern- and regex-based muxes, however, are very
    easy to nitpick and are far from simple.

    Does it add more work to maintain? Yes. But isn't the whole purpose of a
    language/library/framework to shift the burden from programmer to the tools?

    On Friday, May 24, 2013 7:50:58 AM UTC-4, Matt Silverlock wrote:

    http://www.gorillatoolkit.org/**pkg/mux<http://www.gorillatoolkit.org/pkg/mux>and
    http://www.gorillatoolkit.org/**pkg/pat<http://www.gorillatoolkit.org/pkg/pat>are both so incredibly simple to integrate with net/http that replicating
    their functionality in the standard library is only going to add to the
    weight needed each release.

    I can understand the OP's desire to have them included, but including
    everything that "might" be useful to "many" is a dangerous road (where do
    you say no?).

    Each block of functionality you add to the standard library is just more
    work to look after each release cycle.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dgrijalva at May 29, 2013 at 9:24 pm
    You might look at falcore. http://fitstar.github.io/falcore/

    You can think of it as Rack for go. It let's you have before/after filters
    and makes routing trivial.
    On Thursday, May 23, 2013 1:49:08 PM UTC-7, ace....@gmail.com wrote:

    I'm trying to port a large Ruby Sinatra based web app to Go. Love the
    language so far (albeit, the lack of macros, generics, overloading, real
    classes, ternary conditions, string interpolation to name a few are rather
    cumbersome once you've had them all in other languages) but the standard
    library and performance alone make up for the rest (for now :D). But the
    one thing that bothers me with the task at hand is http.HandlFunc won't do
    regexes! Nor is there some way to hook into before/after request handling.
    Is there any chance this might be added to the library? Thanks!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 23, '13 at 8:56p
activeMay 29, '13 at 9:24p
posts26
users13
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase