PHP has json_decode() and json_encode() which do all of this correctly ... GO is interesting, but production ready? Not for awhile.
It also can decode directly into typed structures. An example from the documentation (you'll have to open the linked example): http://golang.org/pkg/encoding/json/#example_Decoder
Anecdotally, a typed version of JSON decoding is much nicer to work with.
How so? Considering that JSON isn't strongly typed.
Why is this nicer?
Let's say you are working with the Reddit API. You can, of course, do it the way you suggested, and just decode the result into an untyped object. However, I find this incredibly brittle. You end up with strings indexing into arrays all over the place.
On the other hand, when you decode into a Go struct, you use the regular dot syntax to access parameters. You can't misspell these or use the value inappropriately (trying to loop over a JSON number, for example). You can write comments on the fields to document what you expect various values to hold. It is nicer in the same sense that using classes is nicer than just using arrays for everything.
Another benefit is of course the improvement of performance. Accessing an string value in a JSON object by a key is the equivalent of a hash table lookup in Python or PHP. It is incrementing a pointer by a constant number in Go (assuming you use strongly typed decoding).
I'll say it again, Go's encoding/json can do what you want (the equivalent of json_decode). There are better alternatives available to users of that package, and the GP was discussing how to exploit one of those better alternatives without having to write the struct by hand (which I personally find a trivial one time cost).
Compiler telling you about a bug because you have a typo in your code (as opposed to blowing up at runtime, sometimes in a way that you won't notice) is also important.
Struct definition is also a documentation of your data. Another developer (or you a month from now) doesn't have to go back and re-read, say, Redit API docs. He (or you) can just re-read definition of the struct and know all the data that a given JSON request provides. That's nice.
An editor can parse the struct definition and give you auto-complete, which is also nice.
First, let me point out that we have moved on to a slightly different topic. The tools that json_decode gives you is available in Go (it would be syntactically awkward, out of a necessity born of Go being statically typed). An example: http://play.golang.org/p/OvshdY1oVQ
However, I would write it as follows http://play.golang.org/p/pODFi9Jrve. This is merely a different way of doing the same thing.
Now, to the topic that we are talking about is the claim that the latter is nicer. I was not comparing PHP and Go when I said that it was nicer (although I have some experience with PHP). I was drawing from my experience with working with JSON in statically typed languages. In particular, working with JSON in C++, Objective-C and Go. In all of these languages, the JSON libraries I used were essentially dynamically typed. I claimed merely that having the JSON library use reflection to deserialize into typed structures is nicer than using NSDictionary's various methods or maps in C++.
In PHP, the syntactic overhead of walking dynamic structures is obviously much lower than the languages I was thinking about, so that criticism is blunted when referring to that language. But I still believe there is some advantage there. A large part of what I find nicer about the latter is indeed the same reason I prefer static typing to dynamic typing. It is impossible to mistype the latter (try changing the ".Foo" to ".Fo" and trying to run the snippet). Consider that doing the equivalent in PHP will simply return NULL (I think), as it is really just doing a dictionary lookup. I fully admit that this is a static versus dynamic thing, not about JSON in particular.
As to the performance thing, I think you too easily discount the importance of low latency. But regardless, I was really comparing to Go's statically typed brethren. They essentially use hashtables for representing parsed JSON objects which is far less than ideal. Note that they don't employ the clever tricks that dynamic languages use. V8, for example, makes JS's objects (which are essentially hashtables) perform significantly better than a mere hashtable.
In pseudo-code-ish:
type FacebookUser struct {
ProfileID int
Name string
....
}
json.Unmarshal(response, FacebookUser)
json_decode($response);
json.parse response
It's certainly why I find it more appealing, anyway. Makes me feel more secure in my code.
Anyway my point, in case you missed it, is that "GO" is not correct.