Money libraries - which do you use and why?

There seem to be 2 Elixir “Money” libs:

and neither one makes reference to the other.

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?

3 Likes

I remember that kipcole9/money took much more time to compile and we replaced it with plain Decimal. https://hexdocs.pm/decimal/readme.html

I used elixirmoney/money also before and it just worked.

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: https://github.com/kipcole9/money#falsehoods-programmers-believe-about-prices 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.

2 Likes

Yepp, I read it. Our use case was quite simple, so we were fine.

1 Like

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.

8 Likes

This is a good summary of the main differences between the 2 libs.
I think this should be made clear in the Github READMEs of both libs.

1 Like

I use https://github.com/elixirmoney/money together with https://github.com/jshmrtn/currency-conversion.

I also contributed to both. They are well written, actively maintained and the authors were helpful. What more do you need?

2 Likes

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

Yes, I think the use of :cldr is an excellent point.

Every library can have its users, there does not have to be a more correct one. Is Phoenix the most correct web framework for Elixir?

With that in mind, I think the 2 libs should reference each other. A new Elixir dev visiting github would not know which lib to choose.

I’m sure the maintainers would appreciate a PR to the readmes (and maybe the docs) to include those references :wink:

1 Like

:wink:

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?

  1. Money must always have both a amount and a currency code.

  2. 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
  3. Money arithmetic can only be performed when both operands are of the same currency.

  4. Money amounts are represented as a Decimal.

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

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

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

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

9 Likes

I think the only thing lacking is for each library to make some reference to the other.

For example…

:money could have this in its README

Looking for something more comprehensive and globally applicable? Look at :ex_money

and :ex_money could have this in its README

Looking for something simple and lighter without any :cldr deps? Look at :money

something like that?

2 Likes

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.