I agree with this sentiment and therefore my Response method is also an `io.ReadCloser` (exposing the http.Response.Body io.ReadCloser that Go has to offer).

I agree with you.

I wrote this library because I didn't want to rewrite those functions every time I started on a new project. I put it online because I figured that I would be useful to others as well.

btw for the record I don't think there's something wrong with making small packages like this, just that I'm more likely to copy over a function or pattern that I like into my codebase, rather than bring in a dependency.

I know... But as you said (and I agreed) :) dependencies add complexity...

I am not trying to do things in the "Python way". I am trying to bring some of the same flexibility I get when using the Python requests library to Go.

Originally the API was completely asynchronous (every "request" function returned a channel).

I got a lot of feedback that I shouldn't do that, so I moved the asynchronous requests to specific functions e.g GetAsync and made the standard API synchronous.

You should go further, removing the async methods altogether. In Go, making sync APIs async is trivial and well-understood.

yes

I am not very good at naming things and figured to just slap a 'g' on requests => grequests.

I figured that I would write the code and decide on a name later...

I'd say goquests to avoid the gore quests issue, just like coroutines => goroutines

And it has a nice implication that you send your app on a quest through HTTP land :)

Jerf,

Thank you for the suggestion. I plan on adding some functionality to make asynchronous APIs friendlier to use (like a `Do` or `Apply` function etc...). But if you don't choose to use the asynchronous APIs everything still functions the same (in fact the asynchronous APIs use the synchronous functions and slap channels on them)

No, seriously, just remove your "asynchronous APIs". You don't need them. They aren't adding anything. Just remove them. Go already does all that.

Oh, what the heck, I'll name names. This is part of why I've been so pissy at the Node community for the past few years. Their definition of synchronous is wrong, and it's really become quite popular. Synchronous does not mean "blocks the whole process". That is a weakness of Node, not a universal programming truth. From the Node perspective, all Go code is always and automatically asynchronous. You don't have to add it. It already is. You're not adding functionality by trying to "nicely" provide an asynchronous API, you're simple redundantly adding what is already there, and what you're adding is significantly less flexible than what Go already provides.

(Now with more correct definitions of the terms, it is meaningful to say that Go code is synchronous within a goroutine. But Go already provides abundant tools for dealing with that within its runtime. We can already compose these tools together trivially to do whatever async patterns we want.)

Now, I suppose, standard disclaimer, this is your library, do as you like. I'm not actually personally passionate about this like I'm yelling at my monitor or anything. I'm trying to help you save time and effort. It's up to you what you decide to do.

Jerf,

1. Thank you for the feedback

As you have already seen, I submitted my library to /r/golang and have gotten a lot of feedback – from which I modified the constructs (originally the functions returned channels).

I want to write something that is useful to as many people as possible (all while not alienating anyone) and therefore try not to force users (like I originally did) to use the "asynchronous APIs".

I didn't expect this to end up on HN and was going to start a discussion on golang-nuts on the pros and cons of this construct. Based on that, I was going to remove or keep the APIs.

+1 for removal, YAGNI.

I definitely support this sentiment w/r/t the single threaded mindset of node and their async all the things approach. The only question with Go is if we guarantee sync libs, then where is the good async example code? I agree libraries should be synchronous, but does it really hurt to not have some best practices "how to do it async" in the docs? or should it be... in the code?

Kind of a meta question, but an interesting one.

The "good asynchronous" code in Golang is straight-line code that would be called "synchronous" in Node.

Part of the problem is that even as an attempt at a "non-synchronous" interface, this seems clumsy. It demand-creates new channels for requests. That doesn't seem right.

Whats wrong with "demand-creating" channels? The Go stdlib does it within their network library https://golang.org/src/net/singleflight.go#L67

Because you can't select on an arbitrary collection of channels.

It might make sense for a library to return a new channel for something you do once, or once per goroutine.

It doesn't make sense to use returned channels as a basis for async dispatch.

> all Go code is always and automatically asynchronous

wat?

I think that was an overstatement, but in the sense we're talking about with an HTTP request library, his overall point is true: Golang's runtime yields to other coroutines on I/O system calls. There usually† isn't much point in designing your own I/O scheduling system in Golang; you're almost always better off just forking off a zillion coroutines and letting them merge their results back across a single channel.

† At least in 1.1, I couldn't write a fast port-scanner without doing my own scheduling, but that's a corner case.

I agree! The README is really sparse right now (I didn't expect so much exposure right). It is just a matter of time before the README has more information.

Thanks – I wrote this library because I like using requests when writing in Python and wanted something similar when writing in Go.

This is true, however with creating applications with Django you are protected against most basic attacks. The ORM uses parameterized queries, all unsafe output is automatically escaped, Protection against CRLF injection within the framework and protection against HTTP response splitting.

The framework isn't fool proof (no one can protect developers from themselves). But I feel that Django does what it needs to do when it comes to protecting its users.

As long as you're using the tools provided, you're doing your due diligence. The framework provides a lot, and the ecosystem usually provides the rest.

The "last mile" is just making sure your code is using all those tools correctly.

Tools won't help when an integer overflow causes (for example) stock to be sold rather than bought.

And yet that example may only be the last item in a threat tree, which may have a zero-day vulnerability at its root.

Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable. If you understand how an attacker might compromise a system (ref. STRIDE) you can mitigate.

> Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable.

Writing everything yourself, as opposed to widely, community tested open-source alternatives, makes your system vulnerable.

Your example seems to be at the farthest possible end of the spectrum from what I'm talking about.

Not suggesting writing everything yourself. I'm suggesting that the use of third party applications, services, frameworks or components will increase the attack surface. Because you've not written that code yourself, there's value in understanding the attack vectors these components etc. present. Knowing those allows you to mitigate threats.

Maybe we come from different backgrounds. Using open source code that's been subject to lots of eyes and lots of use, e.g. a framework like Django, reduces the surface area, to me, because of the shared best-interest of fixing security problems. The key is staying up-to-date.

Not that you shouldn't understand the potential vectors against your site, or shouldn't read how to use these tools correctly, but a widely tested and used tool or framework, just like a widely researched crytpo algorithm, is better than one with no other eyes on it.