4 ms·
>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 str
by rudolf0 12y ago
>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.
- deleted 12y ago[deleted]
- enneff 12y agoWhat 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.
- aikah 12y agoIMHO there is something rigid in Go,like C rigid.Sure,there is no manual memory management.But a modern language shouldnt need explicit pointers.
- enneff 12y ago> 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.
- rudolf0 12y agoI understand pointers and structs just fine, it's just that you would think a modern language like Go would avoid use of pointers to structs and "bring-your-own-buffer" type calling conventions except wherever possible. It makes for ugly developer APIs, in my opinion. That is, in a "friendly" language I expect to generate JSON like this (in pseudocode): HashMap parsed = JSON::parse("{1: 2}"); not JSONObj obj; JSON::populate(&obj, "{1: 2}");
- enneff 12y agoThe former is how it might work in a dynamically typed language. In a statically typed language, like Go, there are great benefits to decoding into the fields of struct with fields of known types.