3 ms·

As others have already pointed out, this was released in 2016 and already discussed on HN [0], and seemingly hasn't taken the world by storm since. But just gla

by danso 6y ago

As others have already pointed out, this was released in 2016 and already discussed on HN [0], and seemingly hasn't taken the world by storm since. But just glancing at the amzn Github activity, and it looks like the docs and the tooling [1] are recently and frequently updated (including a new CLI in Rust [2])? Can anyone currently at Amazon shed some light on how prevalent Ion is internally? [0] https://news.ycombinator.com/item?id=23922278 https://news.ycombinator.com/item?id=23922278 [1] https://github.com/amzn/ion-docs/commits/ https://github.com/amzn/ion-docs/commits/ https://github.com/amzn?q=ion&type=&language= https://github.com/amzn?q=ion&type=&language= [2] https://github.com/amzn/ion-cli https://github.com/amzn/ion-cli

8v-0q_6-drhjp9x 6y ago
I left Amazon a bit over a year ago, after being there seven years. It always struck me as a combination of "not invented here" syndrome and a solution in search of a problem. It has no real world benefits over JSON, the tooling is limited, but you inevitably have to deal with some other team that regrets choosing it and now it's their API. I'm so happy I never have to look at it ever again, and seeing this post today is a real throwback to wasted engineering effort. Just let out go, Amazon.
- xxpor 6y ago
  It has a decimal type. That alone is reason enough for amazon to use it over json.
  - goldenkey 6y ago
    You can easily encode a decimal type as binary data. Not a huge deal.
loukrazy 6y ago
Depends on the part of Amazon but it is pretty prevalent in Retail. The fact that it is both binary and self describing makes it pretty good for data at rest. You can still parse and understand that archival transaction data from 8 years ago. The support for S-Expressions is both a blessing and a curse. The ability to write logic with native data structures in it is fundamentally interesting, but it leads to lots of reinvention of somewhat crappy Lisp implementations. The tooling ecosystem has been slowly improving outside of JVM, particularly the latest JS implementation. In a vacuum, the support for type annotations, timestamps, decimals and binary serialization make it superior to JSON for use cases where self describing data is appropriate.

by danso 6y ago

8v-0q_6-drhjp9x 6y ago

I left Amazon a bit over a year ago, after being there seven years. It always struck me as a combination of "not invented here" syndrome and a solution in search of a problem. It has no real world benefits over JSON, the tooling is limited, but you inevitably have to deal with some other team that regrets choosing it and now it's their API. I'm so happy I never have to look at it ever again, and seeing this post today is a real throwback to wasted engineering effort. Just let out go, Amazon.

xxpor 6y ago
It has a decimal type. That alone is reason enough for amazon to use it over json.
- goldenkey 6y ago
  You can easily encode a decimal type as binary data. Not a huge deal.

loukrazy 6y ago

Depends on the part of Amazon but it is pretty prevalent in Retail. The fact that it is both binary and self describing makes it pretty good for data at rest. You can still parse and understand that archival transaction data from 8 years ago. The support for S-Expressions is both a blessing and a curse. The ability to write logic with native data structures in it is fundamentally interesting, but it leads to lots of reinvention of somewhat crappy Lisp implementations. The tooling ecosystem has been slowly improving outside of JVM, particularly the latest JS implementation. In a vacuum, the support for type annotations, timestamps, decimals and binary serialization make it superior to JSON for use cases where self describing data is appropriate.