
The Arc challenge in Go - marketer
http://github.com/hoisie/web.go/blob/master/examples/arcchallenge.go
======
nostrademons
Won't this return the last input entered by any user, regardless of who
clicks? The spirit of the arc challenge is to output what you typed, not what
anyone types.

~~~
oscardelben
Good catch. I guess when this is true until they implement session management.
Anyways I was surprised by the cleanness of this code.

------
trezor
So basically this doesn't meet the challenge requirements, the code looks
ugly, and yet this is one of the most upvoted stories on HN today?

Would anyone have cared if this was done in VB? I realize Google has done lots
of cool and impressive stuff, but Google-fandom should only be able to go that
far, and this is way beyond.

~~~
ed
I found this interesting because it isn't just a Challenge entry, it's the
introduction of a new Go framework: web.go.

<http://github.com/hoisie/web.go>

------
lucifer
I looked at your couchdb client. Why are you claiming Go can not make
"generic" http requests?

There is already http.Get and http.Post. So why are you exposing http.send
(which obviously is intended to be package private)?

~~~
marketer
The http package can't send delete, head, or put requests. Couchdb uses all of
these methods, not just post and get.

I filed an issue a few weeks ago for this:
<http://code.google.com/p/go/issues/detail?id=155>

~~~
lucifer
Didn't consider that. (But wouldn't it make more sense to copy the code
instead of requiring user change to the package?)

~~~
marketer
Yeah, I agree it isn't the most elegant way to do it, but the alternative is
to keep a copy of go's http package in the gocouch repo, which isn't too
elegant either.

My guess is that within a couple months Go will have a new http client that's
fully-featured (keep-alive requests, authentication, and support for generic
requests). Until then, if people have a burning need to use gocouch, they'll
have to add that small method to the http package. Plus, people are used to
compiling the go source code because it's the only way to install it (no
binary packages yet)

~~~
lucifer
Its not really an issue of elegance. Either way is not pleasing, but given
that your code is the only consumer of the exposed http.Send, my
recommendation is that you isolate your end users from the Go.http's evolution
by including the (dup) code in your source and removing it when the update
release fixes the issue. Transition would be transparent to your end users.

