The "other parsers" in stdlib are gob and encoding/xml.
Gob is a format made for Go, so it does not have a field naming convention mismatch; what's on wire is the Go convention.
encoding/xml isn't really structured as a "convert between equivalent-shaped structs and a message" utility, its struct tags are more like a query language, like a simpler cousin of XPath. Most real-world code using it does things like
type Person struct {
FirstName string `xml:"name>first"`
LastName string `xml:"name>last"`
}
Where as with JSON there was a clear desire to have
{"email": "jdoe@example.com", "name": "John Doe"}
parse with as little noise as possible:
type Person struct {
Email string
Name string
}
woodruffw
Again, I understand the rationale. I just don’t think it was a good idea.
Gob is a format made for Go, so it does not have a field naming convention mismatch; what's on wire is the Go convention.
encoding/xml isn't really structured as a "convert between equivalent-shaped structs and a message" utility, its struct tags are more like a query language, like a simpler cousin of XPath. Most real-world code using it does things like
Where as with JSON there was a clear desire to have parse with as little noise as possible: