> So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node?
Well, for starters, Go is much more awkward for working with JSON than JS is (which is to be expected since JSON is literally a subset of JavaScript). More importantly, Go lacks the ridiculously vibrant ecosystem for Web development that Node has — no NPM, no Connect, no Jade, no Stylus, etc.
So what exactly do you think is awkward about Go's way of working with JSON? Here's a code example from one of my current projects:
type UploadProgress struct {
Progress int `json:"progress"`
}
//...
// variable progress is of type Progress
if json_data, err := json.Marshal(progress); err == nil {
w.Header().Set("Content-Type", "application/json")
w.Write(json_data)
}
json.Unmarshal works the same way. IMHO, not exactly more awkward than using JSON.parse and JSON.stringify.
Unless there's something I missed, json.Unmarshal works the same way iff you have a struct that matches the JSON data very closely. If the JSON data is a little more free-form, you're stuck with a map of interface{}. Having to muck about with types is just a little tedious compared to JavaScript where there aren't really any types and anything can concisely be converted to a string. (I did a little project involving JSON a while ago in Go, but I'm hardly an expert at the language, so if I missed something, I apologize for the misinformation.)
In retrospect, I think I may have overstated it a little bit, and I doubt this problem would crop up too often for most apps.
If your json doesn't represent something that already follows some known structure, you have an opaque data structure that you have to hand write a parser for in any language.
the label on the field lets you denote when that will happen, so... it's not quite as difficult as it may seem; you don't have to write a single method for that case.
The type system is a feature, not an obstacle. Yes, you have to specify a type, but as a result, the compiler can perform a lot of checks that, in dynamically typed languages, would either be something you'd handle manually, something that would cause undefined behavior, or something that you would write a unit test to test for. Yes, you could just wing it, unmarshal some data, have an unsafe reference to some field and hope that it performs the way you want it to, but the reality is that things like that are easy in JavaScript because they're wrong. All data inherently has some kind of type, and different languages deal with that in different ways.
but yes, that particular type of thing does come up a lot, and the topic of handling bad json is one that has woefully too litter literature surrounding it (I've had it stump me before on my own projects). Things like "they're using the wrong format for the timestamp" or "that is sometimes string, sometimes null" are stumbling blocks when coming from dynamically typed languages (I'm coming from Python/JavaScript), but in my experience writing Go, the way the language works makes writing bad code much more difficult, and my Go programs have been much more stable, easy to refactor, and easy to maintain forward progress on over a long period of time. After using it for some time, I've come to the conclusion that these types of tradeoffs have been worthwhile. The significant reduction in runtime errors that I've seen in my Go applications compared to my Python applications have more than outweighed the amount of time I would normally spend debugging and testing my Python code, which is tedious and boring.
After 'go get'ing the package, you can use git/hg/bzr to checkout the specific version you want. From there, all of the Go build tools will work as normal.
I don't think so, but I could be mistaken. (btw, someone pointed that out as a drawback on another thread.)
What I've done sometimes is just clone the repo within a directory that appears in the GOPATH, maybe checkout a specific revision, and that solves the problem.
Well, for starters, Go is much more awkward for working with JSON than JS is (which is to be expected since JSON is literally a subset of JavaScript). More importantly, Go lacks the ridiculously vibrant ecosystem for Web development that Node has — no NPM, no Connect, no Jade, no Stylus, etc.