What does HackerNews think of gojson?
Automatically generate Go (golang) struct definitions from example JSON
Sounds like gojson[0] would make your life a lot easier - it automatically generates the struct definitions for you.
I'd recommend using the JSON to generate your struct definitions, in a schema-like fashion. I wrote a tool to automate that process: https://github.com/ChimeraCoder/gojson
I use this as a step in the build system for the projects, which ensures that the definitions stay in sync with the API clients/servers themselves.
curl -s https://api.github.com/repos/chimeracoder/gojson | gojson -name=Repository
More specific to JSON, you may be looking for something like https://mholt.github.io/json-to-go/ (by the same author) or https://github.com/ChimeraCoder/gojson (which I've used myself).
(I find that what I pay in using a static language like Go to manipulate JSON and having to use a tool like that often comes back to me pretty quickly when I take the tool output as a template and start turning all the structs into Real Objects (TM). The dynamic languages are pretty good at taking JSON and yielding a simple pile of dict/map/array/strings/numbers/etc., but if you want to get real objects back out of them the advantage over Go evaporates. Not because the dynamic languages make it "hard", but just because with one of these tools, both Go and the dynamic solutions are roughly as easy.)
Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson
This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.
In addition to the effects of being statically typed, which you mentioned, Go is a bit lower level than Python or Ruby, so it will always perform at least slightly worse when compared on a strict line-by-line basis. Fortunately, though, it's not that much more verbose in this case. And as an added benefit, the struct value, once unmarshalled, is typesafe (which is not true in Python[1]).
[0] https://github.com/ChimeraCoder/gojson
[1] Because Python is not only dynamically typed but strongly typed, I've more than once run into an issue where a misbehaving API returns a string instead of an int, and then Python throws a runtime exception because it can't add a string and an int.
If it doesn't, then you just use json.RawMessage to defer unmarshalling, but you can still dispatch to a finite number of structs that represent the universe of possible responses.
[0] And no need to write it all out by hand - if you have a single example JSON response, you can generate it automatically: https://github.com/ChimeraCoder/gojson
Shameless but relevant plug - if you do know the structure of your JSON in advance, I wrote a tool for automatically generating the appropriate struct definition for it: https://github.com/ChimeraCoder/gojson
(I see these as complimentary tools, rather than conflicting or competing, since they would have two different use cases).
I originally wrote it when writing a client library to interface with a third-party API; it saves a lot of effort compared to typing out struct definitions manually, and a lot of type assertions compared to using map[string]interface{} everywhere.
If your JSON is effectively "strongly typed" (most APIs are), this is going to be a huge win for you.
If your JSON is not, then you'll have a problem in any statically typed language (not just Go), because you need some way to reason about the type. You'll also have the same problem with dynamically typed languages as well - the main difference is that Go will never do implicit casts (I would view this as a good thing).
I've done a lot of work in Go involving JSON (that's originally why I wrote the above tool - to save myself time), and in practice, it's rare that I have to do anything more than decode, check for an error[0], and then move on.
[0] Which is something everyone should do in all languages, not just Go - once you've confirmed that there is no error, you rid yourself of a lot of possible bugs that could pop up later on in harder-to-discover places.