41–50 of 55 posts
I would say the most idiomatic way is having defined structs and using encoding/json. Even when you don't know the json schema in advance you can still parse it into an interface{}. Here's an example: http://play.golang.org/p/jrqBcPuQei
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
Hint: Not the be confused with ...
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
Earlier quoted context omitted.
>For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct I sometimes have trouble understanding Go. It kind of seems to retain a lot of the bad parts of C in terms of developer-friendliness, while still being relatively slower than C and garbage-collected.
What are you having trouble with in this instance? Pointers and structs? Both are very simple, well understood concepts. Their implementation in Go is also more syntactically clear than in C.
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
I pronounce JSON as "jay-sawn" to avoid the confusion with the name. I've heard "jiss-on" and various other mutations used as well.
Earlier quoted context omitted.
What are you having trouble with in this instance? Pointers and structs? Both are very simple, well understood concepts. Their implementation in Go is also more syntactically clear than in C.
IMHO there is something rigid in Go,like C rigid.Sure,there is no manual memory management.But a modern language shouldnt need explicit pointers.
I don't understand this. Can you clarify why you think this is a good idea?
My experience with languages that have implicit "references" (Python, Java, JavaScript) is that it's not clear when you're sharing and when you're copying data, leading to bugs and unnecessary allocations, respectively.
I would say the most idiomatic way is having defined structs and using encoding/json. Even when you don't know the json schema in advance you can still parse it into an interface{}. Here's an example: http://play.golang.org/p/jrqBcPuQei
It's definitely safer, but it's a living hell having to define a class for each possible json structure in Java with gson.
This looks like a good approach to dealing with heterogeneous JSON! (ie, JSON that has an unknown and/or variable structure.) I've always found encoding/json a little clunky for this. 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 complimenta…
(Another plug here) I did too! Except it runs in the browser: https://mholt.github.io/json-to-go And I agree with you about the complementary aspect. Sometimes you can't control the fact that your JSON will have a widely varying structure... but when you can, these generators are nice.
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
I would prefer something like Jason, even though it sounds like JSON, over something crazy like Unicorn Milk. I'm not saying you were suggesting something crazy, but just adding my two cents.