Live data from Hacker News

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

github.com

141–150 of 174 posts

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

#141
post #61

Earlier quoted context omitted.

That just means == is a "lossy" equivalence relation. I rather the precision be truely observable----every number is "infinite precision". Once can always include natural as extra field if one cares about empirical precision.

I'm having a bit of trouble parsing this, but Ion decimal values are not "infinite precision". Every decimal has a very specific, finite precision. It's a standard "coefficient and exponent" model, with no specification-enforced limit on either.

The idea is each number is adequately precise in that additional precision would mean additional useless trailing zeros.

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

#142
post #77
post #74

Surprised nobody mentioned CBOR ( http://cbor.io ) yet. Aka RFC 7049 ( http://tools.ietf.org/html/rfc7049 ).

It is referenced in the Ion docs: http://amznlabs.github.io/ion-docs/index.html

They complain about how CBOR is a superset of JSON data types and so some CBOR values (like bignum) might not down-convert to JSON cleanly, and then in the next paragraph they talk about how Ion is a superset of JSON data types including 'arbitrary sized integers'. Bad doubletalk. Boo. (I have implemented CBOR in a couple languages and like it. Every few months we get to say, "oh look, _another_ binary JSON.")

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

#143

Big congrats to Todd, Almann, Chris, Henry, and everyone else who made this happen. Several years ago, I wouldn't have imagined this possible and I'm a little bummed that I left before it happened. Like leef said above, I'm glad to have Ion as an option again.

I am curious why you "wouldn't have imagined this possible", is the reason technical or political?

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

#144

Binary values can be stored as base64 in regular old JSON as well. Yes that is bigger but same as email/MIME binary chunks are converted to base64. Email messages and attachments are handled this way, we do this everyday. Base64 does bloat by 40%ish, so the larger content could be compressed/decompressed prior to base64 encoding it and vice versa or even encrypted/decrypted on either end in software/app layer. No nee…

> Binary values can be stored as base64 in regular old JSON as well

But in JSON you'd encode that Base64 as a string and the application must know that the data isn't really a string but a blob of some type of encoding. That probably means wrapping in another struct to provide that metadata. Ion provide a terse method of doing the same while maintaining data integrity:

    'image/gif'::{{ R0lGODlhAQABAIABAP8AAP///yH5BAEAAAEALAAAAAABAAEAAAICRAEAOw== }}
The 'image/gif' annotation is application specific, but all consumers know that the contents of that value are binary. In the binary Ion representation, those 43-bytes are encoded as a 45 byte value (one byte for the type marker and a second for the length in this case; as little as 47 with the annotation and a shared symbol table), making the binary representation very efficient for transferring binary data.

Since Ion is a superset of JSON, it's by definition more complex, but the complexity isn't unapproachable. Most of the engineers I worked with assumed it was JSON until coming across timestamps, annotations, or bare word symbols.

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

#145
post #93

Earlier quoted context omitted.

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).

Integers will do no better at pretending to be a decimal type without a library.

Sure, but most other languages have built-in support for decimal types. Java has BigDecimal, as does Ruby, Python has the decimal module, C# has System.Decimal, the list goes on.

Javascript doesn't even have proper integers to guarantee the functioning of this correctly, it's a really sad state.

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

#146

Earlier quoted context omitted.

Integers will do no better at pretending to be a decimal type without a library.

Sure, but most other languages have built-in support for decimal types. Java has BigDecimal, as does Ruby, Python has the decimal module, C# has System.Decimal, the list goes on. Javascript doesn't even have proper integers to guarantee the functioning of this correctly, it's a really sad state.

>Javascript doesn't even have proper integers to guarantee the functioning of this correctly

I don't understand what you mean at all. Javascript should be able support a decimal library just as easily as a language with integers.

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

#149

Almost every time I see yet another structured data format I'm surprised at the number of people who haven't ever heard of ASN.1, despite it forming the basis of many protocols in widespread use.

10.5.7.34.211.3.7.9.7.3.1.4 YOUAREINTHEHELLOFTHOBJECTIDENTIFIERS.

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

#150

Earlier quoted context omitted.

> 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.

You are choosing a definition of strong typing that supports your argument, but the argument is over the meaning of strong typing to begin with. It's not as if there's some universally accepted definition of strong typing. Like functional programming, functional purity, object oriented, etc.—none of these terms are universally defined.

The fact that "strong typing" has no universal definition is exactly why I think it's not useful.
Post reply on HN