Personally, I use the kipcole9 one, a.k.a :ex_money because it seems to be more well-considered (it uses :cldr_utils) and the author is very active here (Ex_money - money with currency type).
However, my library of choice is “less popular” (less stars and forks) on Github.
So I am wondering what other people think. Is one library better than the other? Is it bad to have 2 competing libraries doing much the same thing? Is it possible to achieve approximate consensus on which library deserves to be the de-facto money library for Elixir?
kipcole9/money takes more time to compile because of :cldr. As per the docs
Cldr attempts to maximise runtime performance at the expense of additional compile time.
When using just :decimal, did you find it hard to account for all of these: GitHub - kipcole9/money: Elixir implementation of Money with Currency Personally I am unable to bear the mental burden of keeping these things in mind when working with money so that’s why I use :ex_money, a.k.a. kipcole9/money.
My take is that the :money library is mostly providing a datatype, while :ex_money is a toolkit of dealing with money, especially in an internationalized fashion.
Some of those factors:
Available currencies
In :money the list of currencies is static/hardcoded and you can only add additional ones. :ex_money depends on :cldr for currencies instead of maintaining a list on it’s own and also has means for adding additional ones.
Rounding rules (a.k.a. business rules of currencies)
With :cldr in the back :ex_cldr does not only know the number of decimal places a currency uses, but also about things like alternate rounding rules, like when cash is supposed to round differently than e.g. accounting.
Formatting :money does only support a single set of default formatting or customized per API call. :ex_money again uses :cldr to adjust formatting to settings matching a certain locale (like the users’).
So all in all it’s :ex_money for me if only for the fact of harnessing the knowledge of a unicode maintained database of those mentioned things as opposed to a library maintainer having a (likely worse) maintained copy of it.
Thank you for contributing to the conversation (and to those libraries!).
For me, I like to keep my apps globally applicable, so I care about the use of :cldr and the ability to configure which locales/countries/currencies my app understands and can work with. Moreover, if you want to use cryptocurrencies, it behooves developers to be able to define their own custom currencies.
What I am looking for is for the community to confirm that one library is “more correct” or “more comprehensive” than the other. I believe, right now, that :ex_money, a.k.a. kipcole9/money is both more correct and comprehensive and yet has less stars and forks on Github (which might influence new Elixir devs).
I do try to be as clear as possible in documentation about the purpose and intent of ex_money. Always happy to accept a PR that makes it clearer! (I’m the author).
Introduction to Money
Money implements a set of functions to store, retrieve, convert and perform arithmetic
on a %Money{} type that is composed of an ISO 4217 currency code and a currency amount.
Money is opinionated in the interests of serving as a dependable library that can underpin accounting and financial applications.
How is this opinion expressed?
Money must always have both a amount and a currency code.
The currency code must always be a valid ISO4217 code. Current and historical currency codes can be used. See the ISO Currency for more information. You can also identify the relevant codes by:
Money.known_currencies/0 returns all the currency codes known to Money
Money.known_current_currencies/0 returns the currency codes currently in use
Money.known_historic_currencies/0 returns the list of historic currency codes
Money.known_tender_currencies/0 returns the list of currencies known to be legal tender
Money arithmetic can only be performed when both operands are of the same currency.
Money amounts are represented as a Decimal.
Money can be serialised to the database as a composite Postgres type that includes both the amount and the currency. For MySQL, money is serialized into a json column with the amount converted to a string to preserve precision since json does not have a decimal type. Serialization is entirely optional.
All arithmetic functions work on a Decimal. No rounding occurs automatically (unless expressly called out for a function, as is the case for Money.split/2).
Explicit rounding obeys the rounding rules for a given currency. The rounding rules are defined by the Unicode consortium in its CLDR repository as implemented by the hex package ex_cldr. These rules define the number of fractional digits for a currency and the rounding increment where appropriate.
Money output string formatting output using the hex package ex_cldr that correctly rounds to the appropriate number of fractional digits and to the correct rounding increment for currencies that have minimum cash increments (like the Swiss Franc and Australian Dollar)
In my company (fintech domain) mostly Decimal as integrates nicely with ecto. The library used to be buggy (I and my coworkers authored a few PRs) but that’s no longer the case. The biggest problem with Decimal now is performance. In case of performance sensitive code we use plain old integers or even NIFs.
