The Arc challenge in Go(github.com)
github.com
The Arc challenge in Go
http://github.com/hoisie/web.go/blob/master/examples/arcchallenge.go
4 comments
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.
Good catch. I guess when this is true until they implement session management. Anyways I was surprised by the cleanness of this code.
Yes you're right :) this assumes that only one user is using the app at a time. web.go doesn't have per-session storage yet
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.
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.
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
http://github.com/hoisie/web.go
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)?
There is already http.Get and http.Post. So why are you exposing http.send (which obviously is intended to be package private)?
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
I filed an issue a few weeks ago for this: http://code.google.com/p/go/issues/detail?id=155
Didn't consider that. (But wouldn't it make more sense to copy the code instead of requiring user change to the package?)
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)
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)
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.