These ports from Python and Ruby (like Martini, for another example) are well-intentioned, but I don't think they're a good idea to use. The original libraries get a lot of their expressive power from polymorphism - Requests gets a tremendous amount of mileage out of letting you pass in keyword arguments to the `get` method, for example.<p>Go prefers that you be more explicit and use more function declarations, even if it means repetition in the library code. When developers try to get around this, you see awkward constructs like the pointer-to-a-config-struct used here.
Very poorly named given Requests has a branch using Gevent that's already called grequests. <a href="https://github.com/kennethreitz/grequests" rel="nofollow">https://github.com/kennethreitz/grequests</a>
Whenever I'm reading through Go code and come across something that uses this sort of abstraction library, I usually just close it and move on. The stdlib is really nice and I find code that stays as "vanilla" Go as possible to be the easiest to read.
What's a use case in Go for an HTTP request library interface that returns a new channel for each request? There's no good way to select on a slice of channels, is there?
As much as I love to see new things written in Go I am not a big fan of directly porting libraries written in different languages. It's not even that they're not idiomatic - I can live with that just fine. But the real power of Go comes from interfaces - two great examples being `io.Reader` and `io.Writer`. Once you can structure your library code so that it reasonably implements these standard interfaces you can do complex stuff in a trivial way. Say I want to get a file via HTTP, encrypt it while getting a hash of plaintext and upload it to say Google Cloud. I can pretty trivially do it by putting one `io.Writer` (Google Cloud) in another (encryption) and another (hashing, via `io.MultiWriter`) and then perform the whole thing using a simple `io.Copy`. This sort of expressive power can be achieved iff all libraries you're using adhere to the same philosophy - which is not the case with ports.
After reading <a href="https://github.com/mozillazg/request" rel="nofollow">https://github.com/mozillazg/request</a>, I found yours looks a little bit better.
Until go fixes it's issues with IPv6 (noticeably: it won't work on IPv6 out-of-the-box), I can't really respect it or consider it "production ready" for anything network related.<p>No, I'm not trolling. #8453 got closed, and immediately, #11081 was opened since it re-broke this.<p>Original issue reported by myself:
<a href="https://github.com/golang/go/issues/8124" rel="nofollow">https://github.com/golang/go/issues/8124</a>
Go is great, its open source. I wish Hacker News open sourced their code so that we knew what they are doing. Scared of having folks game the system? Why not have the community make it the best algorithm possible. Why keep pushing YC all the time? Do they not have enough already? Painters and hackers! ha!