News for hackers. Stuff that matters.
Re:The Crystal Programming Language by 013a on Sunday April 15, 2018 @12:29PM (#16843358)
What exactly frustrates you about Go's JSON handling? In my experience its among the best in typed languages. Define a struct (or just use an untyped map), optionally specify json tags for field names, pass it and the json to json.Unmarshal. Go is literally designed for this use case; systems programming, sharing messages between systems. Compared to other typed languages like Rust or Java, its at least as simple, if not simpler.
Re:The Crystal Programming Language by svs on Sunday April 15, 2018 @01:55PM (#16843878)
Try having a default value for a key in a JSON document that isn't null. In Go, this is pure torture. Then compare with the serde library for Rust. Go's lack of generics makes this kind of use case much harder than reasonable.
Re:The Crystal Programming Language by tigershark on Sunday April 15, 2018 @02:04PM (#16843937)
Compare it with F# type providers where you don’t need to generate any struct and you can access the JSON object in a type safe way with autocompletion in your IDE and maybe you will understand what is frustrating...
Re:The Crystal Programming Language by deforciant on Sunday April 15, 2018 @02:23PM (#16844054)
Hey, I found this tool very useful https://mholt.github.io/json-to-go/ when working with large JSON structs :)
Re:The Crystal Programming Language by IshKebab on Sunday April 15, 2018 @06:12PM (#16845291)
How is that possible? You either need to specify the types up front (like Go) or give up on static type safety (like Python). It's impossible to have both.
Re:The Crystal Programming Language by actsasbuffoon on Sunday April 15, 2018 @10:56PM (#16846378)
Actually, you can have both. Many languages in the ML family (Haskell, F#, etc.) can ensure complete type safety without having to define the shape up-front.

Your data comes out of the JSON structure wrapped in a functor, and you can only access it in ways that deal with missing data.

It’s hypothetically possible to recreate this approach in Python, but I don’t think it would be Pythonic.

Re:The Crystal Programming Language by 013a on Monday April 16, 2018 @06:27PM (#16853419)
Its hypothetically possible to recreate this approach in any language. Grab the item in the map at that key -> check that it exists -> check that the type is what you expect.

Its not idiomatic in most mainstream languages. Except, that's how most JSON libraries which validate against a static structure are implemented, they just abstract the reflection away via some interface.

Re:The Crystal Programming Language by actsasbuffoon on Tuesday April 17, 2018 @05:37PM (#16862529)
> Its hypothetically possible to recreate this approach in any language.

Yes, I didn't mean to imply that I was providing an exhaustive list of languages where this approach could be implemented. I merely mentioned Python because it had been brought up several times in the thread.

> Grab the item in the map at that key -> check that it exists -> check that the type is what you expect.

I'd argue with that phrasing. You don't check for the key, nor do you check the type. That would imply something like an if-statement to ensure the presence of a key, and switching over a type. In such a system, you could forget to check for null, or make some other mistake that causes the program to fail at run time.

The functor approach does not rely on the developer checking anything. It is 100% type safe, enforced by the type system, cannot crash at run time, and does not require you to provide a data type to extract the data into.

Re:The Crystal Programming Language by IshKebab on Monday April 16, 2018 @06:13PM (#16853333)
That sounds like how you have to access JSON data dynamically in any statically typed language.
Re:The Crystal Programming Language by actsasbuffoon on Tuesday April 17, 2018 @05:28PM (#16862465)
But these other languages wouldn't necessarily remain type-safe.

The functor approach doesn't involve any type casting, and null pointer exceptions are impossible.

Re:The Crystal Programming Language by IshKebab on Wednesday April 18, 2018 @06:07AM (#16866070)
So, like this sort of thing:

int JsonValue::getAsInt(int defaultIfError);

Or, in Go:

func (JsonValue*) AsInt() (int64, error)

Or are you just talking about it returning the value as a Rust-style Result sum type?

Re:The Crystal Programming Language by tigershark on Monday April 16, 2018 @03:12AM (#16847201)
Re:The Crystal Programming Language by IshKebab on Monday April 16, 2018 @06:06PM (#16853277)
That says you need a JSON schema file, which is deciding the type up front and basically how Go works too.
Re:The Crystal Programming Language by lenkite on Monday April 16, 2018 @09:02PM (#16854501)
You don't necessarily need a schema file. You can take a sample document as input for an inferred type. This is compile type meta programming

https://fsharp.github.io/FSharp.Data/

https://medium.com/@maximcus/magic-of-f-type-providers-225b1...

Re:The Crystal Programming Language by aczerepinski on Sunday April 15, 2018 @01:16PM (#16843652)
Agreed. Go is wonderful with JSON. Reasonable defaults and very flexible.
Re:The Crystal Programming Language by tigershark on Sunday April 15, 2018 @02:08PM (#16843952)
From what I know about go and JSON and what is possible in other languages I would never call it wonderful.
Re:The Crystal Programming Language by 3pt14159 on Sunday April 15, 2018 @01:39PM (#16843779)
It might be wonderful now, but I first used Go in 2009 and it was really hard to work with back then, so maybe the OP has a warped view of the current state?
Re:The Crystal Programming Language by ccccccccccccc on Sunday April 15, 2018 @01:56PM (#16843891)
That was almost 9 years ago. Go has changed at a pretty rapid pace since then.