3 ms·
Just because it’s convenient doesn’t make it a good idea! It’s also not what Go’s other parsers do per the rest of the post.
by woodruffw 1y ago
Just because it’s convenient doesn’t make it a good idea! It’s also not what Go’s other parsers do per the rest of the post.
- yencabulator 1y agoThe "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 1y agoAgain, I understand the rationale. I just don’t think it was a good idea.