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
- 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
- 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
- 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 usehttp://labix.org/mgo.
If I want to talk to MySQL, I would
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.
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.