7 ms·

Show HN: Jason – A new JSON Library for Go

106 points by antonholmquist 12y ago

deleted 12y ago
[deleted]
- bluehazed 12y ago
  Looks like it reduces initial cost of creating structures, etc for JSON data received and makes accessing the data easier. The author does seem to say the library is more focused on reading the data rather than writing it. Whether or not this is a benefit or not is up to you and your use case I guess.
- antonholmquist 12y ago
  Thanks for your feedback. I created the library simply because it just fits my use cases better. I have used encoding/json quite a lot, and for instance, I think golang's strict types makes it inconvenient to dig through arbitrary maps in a quick way. That's what the Get-method in Jason is trying to solve. Similar to how bitly/go-simplejson does it, but with some fine tuning.
  - ryanlschneider 12y ago
    Speaking of the .Get method, wouldn't returning an error alongside the value instead of just the default object be more idiomatic?
    - libria 12y ago
      It looks like .Get uses the null pattern (ie, returns a Jason struct with data = `nil` if nothing is found). Your way is more idiomatic, but it looks like his point with this library is to access the data conveniently in exchange for type-safety. `exists()` can verify something was found if needed.
    - courtf 12y ago
      I think it would be nice to return a bool, rather than an error. It really is just a binary condition and this pattern fits nicely with accessing values in maps. That said, I haven't really found a need for a .Get method in my own code, and will probably just stick with encoding/json for the time being.
- collinvandyck76 12y ago
  Here this nice person created something for themselves and decided to share it with others and this is your reaction. There are a number of ways to express the question "What are the advantages of using this tool over the stdlib?" without coming across as needlessly confrontational. It's unfortunate that so many of these "Show HN" threads turn into this.
  - throwaway90446 12y ago
    I was genuinely curious, hence my question. I did not realize HN had the requirement that all posts be run through some sort of psychic expectation filter that magically tells me the exact mental state of other people and how the post will "come across" to them. But ok, I will delete the post anyway.
- masklinn 12y ago
  It seems to be much easier to use when dealing with very dynamic documents (variable or partially unknown structure), or when only needing a small subset of a complex document.
danso 12y ago
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"
- antonholmquist 12y ago
  Haha, okay. Yes, I just really like the name since it originates from an email sent from one of the project managers at our office: "Don't worry. We can handle both XML and Jason".
- userbinator 12y ago
  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.
  - izolate 12y ago
    American? The North American accent pronounces "Python" similarly, as "py-THAWN" instead of "PIE-thn".
    - randallsquared 12y ago
      I usually pronounce it that way as well, I'm American, and it does rhyme with Python that way for me.
  - JasonFruit 12y ago
    I pronounce it Jay-Ess-Owe-Enn, for obvious reasons.
- todd3834 12y ago
  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.
  - 12y ago
chimeracoder 12y ago
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 https://github.com/ChimeraCoder/gojson (I see these as complimentary tools, rather than conflicting or competing, since they would have two different use cases).
- endymi0n 12y ago
  This. If your main use case is JSON as a serialized representation of the ever same object (plus or minus a few optional fields), encoding/json is by far the fastest and most typesafe way to go. (edit: Protip - for the really really fastest way to demarshal JSON, look here https://github.com/pquerna/ffjson https://github.com/pquerna/ffjson for some reflection-free extra speed after your code has settled down) But if your objects can be heterogenous for whatever reasons (think third-party systems, different languages, legacy stacks...) or you're dealing with different kinds of objects landing on the same controller, jason is the perfect complimentary device to deal with more dynamic structures. I've long sought for something like this, thanks to the OP!
- mholt 12y ago
  (Another plug here) I did too! Except it runs in the browser: https://mholt.github.io/json-to-go 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.
  - anonfunction 12y ago
    Great tool!
  - antonholmquist 12y ago
    Seems very handy! Thank you
jamieomatthews 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, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
- joncooper 12y ago
  Or to do a streaming parse with json.Decoder.
- chimeracoder 12y ago
  > There is no easy way to sort of "parse" json piece by piece, which is what this library provides Well, you can use json.RawMessage to delay decoding until other values are known[0]. However, this still requires that the input set is known at compile-time, which may not always be the case (some APIs sadly use a highly variable JSON schema, which can only be determined at runtime.) You also don't need to pass a pointer to a struct. For example, you can pass an interface{}, which allows you to decode data into a type that is specified by the calling function, which I made heavy use of in this Twitter client library, for example[1]. (This is more or less how encoding/json itself works under the surface, when you think about it, but oftentimes people forget to take advantage of this idiom in practice.) [0] http://golang.org/pkg/encoding/json/#RawMessage http://golang.org/pkg/encoding/json/#RawMessage [1] https://github.com/ChimeraCoder/anaconda/blob/master/users.go https://github.com/ChimeraCoder/anaconda/blob/master/users.g...
- landr0id 12y ago
  > There is no easy way to sort of "parse" json piece by piece You mean like this? http://play.golang.org/p/mMh7HGuTbe http://play.golang.org/p/mMh7HGuTbe
  - anonfunction 12y ago
    You're still parsing the entire JSON document at once. I believe what OP meant was getting a nested property without all the overhead of writing structs or parsing the entire JSON object into an interface{}, []string, map or whatever else is appropriate.
anonfunction 12y ago
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 http://play.golang.org/p/jrqBcPuQei
- mrweasel 12y ago
  You can parse JSON into an interface, but you end up doing tiresome casts if you structure is just somewhat nested.
  - seletskiy 12y ago
    ...or use very simple lib like this one [1] to access to deep-nested structs using one call. [1] https://github.com/zazab/zhash https://github.com/zazab/zhash
- Igglyboo 12y ago
  It's definitely safer, but it's a living hell having to define a class for each possible json structure in Java with gson.
  - anonfunction 12y ago
    Not sure where Java came into the conversation but I found a service[1] which I find really helpful for generating Golang structs from JSON. There is also a CLI tool[2] that does the same. [1]http://mholt.github.io/json-to-go/ http://mholt.github.io/json-to-go/ [2]https://github.com/ChimeraCoder/gojson https://github.com/ChimeraCoder/gojson
    - eikenberry 12y ago
      Another one. https://github.com/str1ngs/jflect https://github.com/str1ngs/jflect
- heavenlyhash 12y ago
firemancoder 12y ago
This is awesome. I built a small API type application with this but it was nowhere near production stable. This library is a step in the right direction
w4rh4wk5 12y ago
this looks quite familiar: https://github.com/likexian/simplejson-go https://github.com/likexian/simplejson-go if anyone is interested i did some slight modifications to the project above which are keep in my personal fork: https://github.com/W4RH4WK/simplejson https://github.com/W4RH4WK/simplejson
gorbachev 12y ago
The name is a little "unfortunate", give that there's a JSON editor for Mac OS X with the exact same name.
- stonogo 12y ago
  Fortunately the go community has long experience with ignoring naming conflicts.

106 points by antonholmquist 12y ago

deleted 12y ago

[deleted]

bluehazed 12y ago
Looks like it reduces initial cost of creating structures, etc for JSON data received and makes accessing the data easier. The author does seem to say the library is more focused on reading the data rather than writing it. Whether or not this is a benefit or not is up to you and your use case I guess.
antonholmquist 12y ago
Thanks for your feedback. I created the library simply because it just fits my use cases better. I have used encoding/json quite a lot, and for instance, I think golang's strict types makes it inconvenient to dig through arbitrary maps in a quick way. That's what the Get-method in Jason is trying to solve. Similar to how bitly/go-simplejson does it, but with some fine tuning.
- ryanlschneider 12y ago
  Speaking of the .Get method, wouldn't returning an error alongside the value instead of just the default object be more idiomatic?
  - libria 12y ago
    It looks like .Get uses the null pattern (ie, returns a Jason struct with data = `nil` if nothing is found). Your way is more idiomatic, but it looks like his point with this library is to access the data conveniently in exchange for type-safety. `exists()` can verify something was found if needed.
  - courtf 12y ago
    I think it would be nice to return a bool, rather than an error. It really is just a binary condition and this pattern fits nicely with accessing values in maps. That said, I haven't really found a need for a .Get method in my own code, and will probably just stick with encoding/json for the time being.
collinvandyck76 12y ago
Here this nice person created something for themselves and decided to share it with others and this is your reaction. There are a number of ways to express the question "What are the advantages of using this tool over the stdlib?" without coming across as needlessly confrontational. It's unfortunate that so many of these "Show HN" threads turn into this.
- throwaway90446 12y ago
  I was genuinely curious, hence my question. I did not realize HN had the requirement that all posts be run through some sort of psychic expectation filter that magically tells me the exact mental state of other people and how the post will "come across" to them. But ok, I will delete the post anyway.
masklinn 12y ago
It seems to be much easier to use when dealing with very dynamic documents (variable or partially unknown structure), or when only needing a small subset of a complex document.

danso 12y ago

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"

antonholmquist 12y ago
Haha, okay. Yes, I just really like the name since it originates from an email sent from one of the project managers at our office: "Don't worry. We can handle both XML and Jason".
userbinator 12y ago
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.
- izolate 12y ago
  American? The North American accent pronounces "Python" similarly, as "py-THAWN" instead of "PIE-thn".
  - randallsquared 12y ago
    I usually pronounce it that way as well, I'm American, and it does rhyme with Python that way for me.
- JasonFruit 12y ago
  I pronounce it Jay-Ess-Owe-Enn, for obvious reasons.
todd3834 12y ago
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.
- 12y ago

chimeracoder 12y ago

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 https://github.com/ChimeraCoder/gojson (I see these as complimentary tools, rather than conflicting or competing, since they would have two different use cases).

endymi0n 12y ago
This. If your main use case is JSON as a serialized representation of the ever same object (plus or minus a few optional fields), encoding/json is by far the fastest and most typesafe way to go. (edit: Protip - for the really really fastest way to demarshal JSON, look here https://github.com/pquerna/ffjson https://github.com/pquerna/ffjson for some reflection-free extra speed after your code has settled down) But if your objects can be heterogenous for whatever reasons (think third-party systems, different languages, legacy stacks...) or you're dealing with different kinds of objects landing on the same controller, jason is the perfect complimentary device to deal with more dynamic structures. I've long sought for something like this, thanks to the OP!
mholt 12y ago
(Another plug here) I did too! Except it runs in the browser: https://mholt.github.io/json-to-go 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.
- anonfunction 12y ago
  Great tool!
- antonholmquist 12y ago
  Seems very handy! Thank you

jamieomatthews 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, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides

joncooper 12y ago
Or to do a streaming parse with json.Decoder.
chimeracoder 12y ago
> There is no easy way to sort of "parse" json piece by piece, which is what this library provides Well, you can use json.RawMessage to delay decoding until other values are known[0]. However, this still requires that the input set is known at compile-time, which may not always be the case (some APIs sadly use a highly variable JSON schema, which can only be determined at runtime.) You also don't need to pass a pointer to a struct. For example, you can pass an interface{}, which allows you to decode data into a type that is specified by the calling function, which I made heavy use of in this Twitter client library, for example[1]. (This is more or less how encoding/json itself works under the surface, when you think about it, but oftentimes people forget to take advantage of this idiom in practice.) [0] http://golang.org/pkg/encoding/json/#RawMessage http://golang.org/pkg/encoding/json/#RawMessage [1] https://github.com/ChimeraCoder/anaconda/blob/master/users.go https://github.com/ChimeraCoder/anaconda/blob/master/users.g...
landr0id 12y ago
> There is no easy way to sort of "parse" json piece by piece You mean like this? http://play.golang.org/p/mMh7HGuTbe http://play.golang.org/p/mMh7HGuTbe
- anonfunction 12y ago
  You're still parsing the entire JSON document at once. I believe what OP meant was getting a nested property without all the overhead of writing structs or parsing the entire JSON object into an interface{}, []string, map or whatever else is appropriate.

anonfunction 12y ago

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 http://play.golang.org/p/jrqBcPuQei

mrweasel 12y ago
You can parse JSON into an interface, but you end up doing tiresome casts if you structure is just somewhat nested.
- seletskiy 12y ago
  ...or use very simple lib like this one [1] to access to deep-nested structs using one call. [1] https://github.com/zazab/zhash https://github.com/zazab/zhash
Igglyboo 12y ago
It's definitely safer, but it's a living hell having to define a class for each possible json structure in Java with gson.
- anonfunction 12y ago
  Not sure where Java came into the conversation but I found a service[1] which I find really helpful for generating Golang structs from JSON. There is also a CLI tool[2] that does the same. [1]http://mholt.github.io/json-to-go/ http://mholt.github.io/json-to-go/ [2]https://github.com/ChimeraCoder/gojson https://github.com/ChimeraCoder/gojson
  - eikenberry 12y ago
    Another one. https://github.com/str1ngs/jflect https://github.com/str1ngs/jflect
heavenlyhash 12y ago

firemancoder 12y ago

This is awesome. I built a small API type application with this but it was nowhere near production stable. This library is a step in the right direction

w4rh4wk5 12y ago

this looks quite familiar: https://github.com/likexian/simplejson-go https://github.com/likexian/simplejson-go if anyone is interested i did some slight modifications to the project above which are keep in my personal fork: https://github.com/W4RH4WK/simplejson https://github.com/W4RH4WK/simplejson

gorbachev 12y ago

The name is a little "unfortunate", give that there's a JSON editor for Mac OS X with the exact same name.

stonogo 12y ago
Fortunately the go community has long experience with ignoring naming conflicts.