Re:Amazon Ion
by 8v-0q_6-drhjp9x on Wednesday July 22, 2020 @11:43PM
(#23923965)
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.
It has a decimal type. That alone is reason enough for amazon to use it over json.
You can easily encode a decimal type as binary data. Not a huge deal.
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.
Can anyone currently at Amazon shed some light on how prevalent Ion is internally?
[0] https://news.ycombinator.com/item?id=23922278
[1] https://github.com/amzn/ion-docs/commits/ https://github.com/amzn?q=ion&type=&language=
[2] https://github.com/amzn/ion-cli