JSON, interfaces, and go generate(talks.golang.org)
talks.golang.org
JSON, interfaces, and go generate
http://talks.golang.org/2015/json.slide#1
36 comments
In case anyone else is sitting looking at the first slide, clicking, scrolling and so on, and seeing nothing else. Press left and right arrow keys.
One would expect people have figured online slideshows by now. It's the 10,000 one that's posted on HN for example...
Miaow, nice passive aggression.
It's the first one people have come across with no way to navigate without a keyboard. It seemed to people a very odd UI, given that many web connected devices don't have them.
s/people/I/g
It's the first one people have come across with no way to navigate without a keyboard. It seemed to people a very odd UI, given that many web connected devices don't have them.
s/people/I/g
I dunno, seems like clicking on the next slide, or the edges of the current slide works just fine for navigation as far as mouse controls goes, and swiping is also working fairly well on my mobile devices, though I can't claim to have tested all possible mobile devices, so your mileage may vary.
Hey would you look at that, I could have sworn that didn't work for me earlier. Hey ho!
Works just fine on my keyboard-less phone.
>Miaow, nice passive aggression.
I think you conflate passive aggression with open derision.
Regarding the former "passive-aggressive behavior is characterized by a habitual pattern of passive resistance to expected work requirements, opposition, stubbornness, and negativistic attitudes in response to requirements for normal performance levels expected of others".
I don't think a snarky response qualifies.
>It's the first one people have come across with no way to navigate without a keyboard.
Lots of web slideshows only navigate with a keyboard. I've seen the same question/answer several times in the past on HN.
It's not like it should take more than 5 seconds to try to press "->" and see what happens....
I think you conflate passive aggression with open derision.
Regarding the former "passive-aggressive behavior is characterized by a habitual pattern of passive resistance to expected work requirements, opposition, stubbornness, and negativistic attitudes in response to requirements for normal performance levels expected of others".
I don't think a snarky response qualifies.
>It's the first one people have come across with no way to navigate without a keyboard.
Lots of web slideshows only navigate with a keyboard. I've seen the same question/answer several times in the past on HN.
It's not like it should take more than 5 seconds to try to press "->" and see what happens....
This is something I really don't like about Go.
80 lines of code to parse some JSON?
Meanwhile, in ruby...
80 lines of code to parse some JSON?
Meanwhile, in ruby...
foo = JSON.parse(STDIN.read)It is no where near 80 lines required to parse JSON.
http://play.golang.org/p/H5yFV6VYaT
There is some boiler plate, since you have a typed system, so you must define your types. Beyond that two lines of Go will parse a JSON blob.
Such as the example of converting the JSON time string into a Time type.
edit: updated the example link
http://play.golang.org/p/H5yFV6VYaT
There is some boiler plate, since you have a typed system, so you must define your types. Beyond that two lines of Go will parse a JSON blob.
people := []Person{}
json.Unmarshal(json, &people)
Such as the example of converting the JSON time string into a Time type.
edit: updated the example link
How does this deal with deserializing json arrays? Unless you have reified generics it's impossible. This is a common headache when working with Jackson.
The example linked and described already deals with deserializing json arrays. What trouble exactly are you experiencing?
Sorry I actually meant Lists. In Java List<String> is just List (since they aren't reified) at compile time so you have to explicitly deserialize an String[] and then manually throw it into an ArrayList<String>.
Not the parent, but my biggest issue with arrays and nested objects is this:
Most JSON arrays come in the form
Another example is this:
Most JSON arrays come in the form
{
"objects": [{"foo": "bar"}, ...]
}
Another example is this:
type Address struct {
street string
city string
}
{
"name": "John Doe",
"address": {
"street": "Some street 1",
"city": "Footown"
},
...
}
For deeply nested structures, it'll always be a bit of a hassle. In your toy example, you can use struct literals to get to the guts of the object quickly.
https://play.golang.org/p/VE90fwT0sE
https://play.golang.org/p/VE90fwT0sE
Meanwhile, in Ruby...foo could contain any conceivable data structure, which you'll have to reflect on and test against extensively in a production environment if you don't want your application falling flat on its face at the first sign of unexpected input.
Go would have similar problems with unexpected input, it just frontloads the work, so if you do something stupid then you'll know it up front.
Go would have similar problems with unexpected input, it just frontloads the work, so if you do something stupid then you'll know it up front.
which you'll have to reflect on and test against extensively if you don't want your application falling flat on its face
Even with full blown JSON schema validation we'd arrive at 2 lines of ruby code plus ~5 for the schema.
Even with full blown JSON schema validation we'd arrive at 2 lines of ruby code plus ~5 for the schema.
So 2 lines of Go and ~5 for the struct. Is your argument that the schema is defined outside of Ruby and therefore doesn't count as LOC?
Not a very fair comparison due to Go's (mostly) static typing and Ruby's very dynamic typing.
In this case, the author wants to use a struct with custom user-defined types as members, while JSON only has concepts of primitive types. That's why you're going to need a lot more code than you would otherwise.
I agree there needs to be a better way to do it though. And "go generate" seems like the hackiest thing in the world for 95% of use cases, including this one.
In this case, the author wants to use a struct with custom user-defined types as members, while JSON only has concepts of primitive types. That's why you're going to need a lot more code than you would otherwise.
I agree there needs to be a better way to do it though. And "go generate" seems like the hackiest thing in the world for 95% of use cases, including this one.
For what it's worth, you don't need to even need to type out the struct manually when unmarshalling JSON; you can generate it automatically[0] (this tool is compatible with `go generate`).
In addition to the effects of being statically typed, which you mentioned, Go is a bit lower level than Python or Ruby, so it will always perform at least slightly worse when compared on a strict line-by-line basis. Fortunately, though, it's not that much more verbose in this case. And as an added benefit, the struct value, once unmarshalled, is typesafe (which is not true in Python[1]).
[0] https://github.com/ChimeraCoder/gojson
[1] Because Python is not only dynamically typed but strongly typed, I've more than once run into an issue where a misbehaving API returns a string instead of an int, and then Python throws a runtime exception because it can't add a string and an int.
In addition to the effects of being statically typed, which you mentioned, Go is a bit lower level than Python or Ruby, so it will always perform at least slightly worse when compared on a strict line-by-line basis. Fortunately, though, it's not that much more verbose in this case. And as an added benefit, the struct value, once unmarshalled, is typesafe (which is not true in Python[1]).
[0] https://github.com/ChimeraCoder/gojson
[1] Because Python is not only dynamically typed but strongly typed, I've more than once run into an issue where a misbehaving API returns a string instead of an int, and then Python throws a runtime exception because it can't add a string and an int.
Meanwhile, in F#...
type People = JsonProvider<"http://someurl.com/people.json">
let people = People.GetSamples()
That is both awesome and slightly scary. This type can literally by MITMd. Maybe we'll see a big push for https-everywhere in F# code?
It is pretty awesome that languages exist that let you do this.
It is pretty awesome that languages exist that let you do this.
As far as I understand the type providers evaluate the samples at compile time. This means that you have at that point of a time a correct version of the data samples. If at compile time everything is ok there is no security or corruption issue for the runtime.
I also think it won't be a good idea to just pull in arbitrary code (or resources) through http(s) during compilation. I think what you really should do is download the files, review them, add them as resources to your project and use those as input for the type providers.
I also think it won't be a good idea to just pull in arbitrary code (or resources) through http(s) during compilation. I think what you really should do is download the files, review them, add them as resources to your project and use those as input for the type providers.
For sure. It's fun to mess around with type providers over https, but not in production. The whole point is to have a (relatively) stable schema.
Meanwhile in Haskell
instance FromJSON Person where
parseJSON = withObject "Person" $ \o -> do
name <- o .: "name"
age <- o .: "age"
return (Person name age)
let person = case decode some_bytestring of
Success p -> p
Error e -> error "Malformed JSON"
Certainly compact; as written, though, it has a few deficiencies compared to the Go version:
1. no specific error messages; these take up a good portion of the Go code, although they could certainly be more automatic;
2. does not allow the same code to be used for encoding and decoding (i.e. you don't have to write a list of fields twice, and can specify which format to encode to/decode from once rather than separately specifying the encoding and decoding functions - note that the format may not be uniquely determined by the final type you want in the output, e.g. you just want a generic date value out, but you need to use a specific date format for the JSON conversion).
The first is more of a nitpick (are those going to show up in 'e' anyway?), but the second is important. Do popular Haskell JSON libraries have a way to do that?
Also, reflection is not really stepping outside the language.
1. no specific error messages; these take up a good portion of the Go code, although they could certainly be more automatic;
2. does not allow the same code to be used for encoding and decoding (i.e. you don't have to write a list of fields twice, and can specify which format to encode to/decode from once rather than separately specifying the encoding and decoding functions - note that the format may not be uniquely determined by the final type you want in the output, e.g. you just want a generic date value out, but you need to use a specific date format for the JSON conversion).
The first is more of a nitpick (are those going to show up in 'e' anyway?), but the second is important. Do popular Haskell JSON libraries have a way to do that?
Also, reflection is not really stepping outside the language.
Errors do indeed percolate down to 'e' at the end.
Data.Aeson.TH[1] can automatically generate JSON decoders and encoders for data types, if that's what you want.
[1] http://hackage.haskell.org/package/aeson-0.8.0.2/docs/Data-A...
Data.Aeson.TH[1] can automatically generate JSON decoders and encoders for data types, if that's what you want.
[1] http://hackage.haskell.org/package/aeson-0.8.0.2/docs/Data-A...
Not the same due to types... the win being reliability and security due to more precise input validation. The loss is programmer time and overall code bloat/complexity, both for the spec and the handling.
Architecturally, it would have been better to separate the spec. When I saw the intro I thought they were going to generate Go from a JSON Schema (which would have been at least more cross platform and reusable). Instead, we got more Go. Meh.
Architecturally, it would have been better to separate the spec. When I saw the intro I thought they were going to generate Go from a JSON Schema (which would have been at least more cross platform and reusable). Instead, we got more Go. Meh.
It's quite possible to write a parse method in go such that
foo := json.Parse(os.Stdin)
var foo SomeType
err := json.NewDecoder(os.Stdin).Decode(&foo)When the code is significantly faster I'll take some extra work to accomplish a goal.
[deleted]