68 karma · joined October 28, 2010
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.
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.
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.
I figured that I would write the code and decide on a name later...
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)
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.
P.S Even though within the article the python the he explains what he means (with type bugs) such issues won't be by moving to python.
One of the best ways to get any bug fixed in any Library, OS etc... is to find a way to exploit it.