Live data from Hacker News

Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

github.com

91–100 of 174 posts

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#91
post #87

Earlier quoted context omitted.

By your definition, any language with strings is weakly typed, since you can always interpret a string as being something else. Strongly/weakly typed has never been a particularly useful description (as the page you linked notes), and I think it's particularly unhelpful here.

> By your definition, any language with strings is weakly typed, since you can always interpret a string as being something else No, I wouldn't say that's the case. For example, in PHP you can literally write: if (1 == "1") { ... ... and the condition evaluates to true. You can do similar things in Excel; Excel doesn't even really differentiate between those two values in the first place. (At least that's how it seem…

> You can't misuse any kind of Ion value that is a string as if it were a timestamp without performing an explicit conversion.

The same is true of JSON. There is no difference, except that Ion has a timestamp type and JSON does not.

If you disagree, please identify what characteristic of Ion's design makes it more strongly typed than JSON, other than the set of types that is built in.

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#92
post #34

Earlier quoted context omitted.

move the decimal and use an int (cents in US). It still blows me away that javascript has become so popular on the server without 64bit int types.

Do you really need those extra 11 bits? Javascript numbers accurately represent integers up to 2^53 - 1. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I just did some ownership percentage stuff where it's not uncommon to go 16 decimal places out...working with JavaScript on this was a pain. Never thought I'd care about that .00000000000001 difference hah...

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#93
post #34

Earlier quoted context omitted.

move the decimal and use an int (cents in US). It still blows me away that javascript has become so popular on the server without 64bit int types.

Do you really need those extra 11 bits? Javascript numbers accurately represent integers up to 2^53 - 1. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Until you need to deal with decimals instead of floats, then you are going to hate yourself because you have to pull in some third party library because the language treats every single number as a float (and floating point errors are a lot more common than most people think even when they are adding together simple numbers).

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#94
post #85

So far, most of the interesting bits I see in Ion are covered in YAML (which is also JSON-superset). Most of the rest are extra types, which YAML allows you to implement. The only really missing bit is the binary encoding... but that seems unrelated to the text format itself. This really looks like a NIH specification.

Ion's equivalently-expressive text and binary formats is absolutely central to its design, and IMO one of its most compelling features. You don't have to choose between "human readable" or "compact and fast", you can switch between them at will. This helps Ion meet the requirements of a broader set of applications, eliminating the cost and complexity and impedance-mismatch problems you get by transforming between mul…

I get that binary format is nice, but I just don't get why instead of adding binary format to an existing good text format Amazon decided to first extend a poor text format and then add binary to that.

Basically: Ion == JSON + extra features + binary format spec. But Ion ~= YAML + binary format spec. You're going to write a new serializer/deserializer in both cases anyway, but in the second one, at least you get the text part for free in almost any language available.

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#95
post #87

Earlier quoted context omitted.

> By your definition, any language with strings is weakly typed, since you can always interpret a string as being something else No, I wouldn't say that's the case. For example, in PHP you can literally write: if (1 == "1") { ... ... and the condition evaluates to true. You can do similar things in Excel; Excel doesn't even really differentiate between those two values in the first place. (At least that's how it seem…

> You can't misuse any kind of Ion value that is a string as if it were a timestamp without performing an explicit conversion. The same is true of JSON. There is no difference, except that Ion has a timestamp type and JSON does not. If you disagree, please identify what characteristic of Ion's design makes it more strongly typed than JSON, other than the set of types that is built in.

[deleted]

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#96

I Consider this Harmful (TM) and will oppose the adoption in every organization where I have an opportunity to voice such. (In its present form, to be clear!) There is no need to have a null which is fragmented into null.timestamp, null.string and whatever. It will complicate processing. Just because you know the type of some element is timestamp, you must worry whether or not it is null and what that means. There sh…

> It will complicate processing.

In practice, it doesn't. If you want to know if an IonValue is null, ask it with #isNull. If you don't care about the null's type, ignore it. On the other hand, the type is an additional form of metadata which allows overloading the meaning of a value.

nulls can also be annotated, so Ion doesn't really have the concept of a singular shared null sentinel.

More so than JSON, Ion often uses nulls to differentiate presence from value (that is, the lack of a field in a struct has a different meaning the presence of that field with a null value). Since nulls are objects, they can be tested separately from the lack of a field definition.

> a timestamp is clearly an aggregate and should be understood as corresponding to some structure type.

Timestamps are structured types with a literal representation that is explicitly modeled in the specification. You're free to ignore it and use a custom schema for representing time, but you've moved any validation into your application at that point and are no better off than JSON.

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#98
post #11

Finally! I've had to live the JSON nightmare since I left Amazon. Some of the benefits over JSON: * Real date type * Real binary type - no need to base64 encode * Real decimal type - invaluable when working with currency * Annotations - You can tag an Ion field in a map with an annotation that says, e.g. its compression ("csv", "snappy") or its serialized type ('com.example.Foo'). * Text and binary format * Symbol ta…

> * Real decimal type - invaluable when working with currency

I believe that the proper way to handle money is to use Integer values plus a pre-defined precision.

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#99

Do any of the popular message serialization formats have first class support for algebraic data types? It seems like every one I've researched has to be hacked in some way to provide for sum types.

Nearly the same question was recently asked in r/haskell:

https://www.reddit.com/r/haskell/comments/4fhuw3/json_for_ad...

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#100

Open question to anyone reading this: Would you use Ion if you were designing a new house-wide message queue? (e.g. broadcast messages to /Home/Lounge/Lights/ to turn on/off)

Maybe, when Ion gets supports for most major languages. I won't touch it now because it means to go Java for every application that reads or writes to that queue. Not because of Java, but because it's only one language. It should get on par with support for the other formats listed in the comments before one should be confident to use it.
Post reply on HN