slouchpie
Money libraries - which do you use and why?
There seem to be 2 Elixir “Money” libs:
- GitHub - elixirmoney/money: Elixir library for working with Money safer, easier, and fun... Is an interpretation of the Fowler's Money pattern in fun.prog. · GitHub
- GitHub - ex-money/money: Elixir implementation of Money with Currency · GitHub
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?
Most Liked
kip
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/0returns all the currency codes known toMoneyMoney.known_current_currencies/0returns the currency codes currently in useMoney.known_historic_currencies/0returns the list of historic currency codesMoney.known_tender_currencies/0returns 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 forMoney.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)
LostKobrakai
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:moneythe list of currencies is static/hardcoded and you can only add additional ones.:ex_moneydepends on:cldrfor 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:cldrin the back:ex_cldrdoes 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
:moneydoes only support a single set of default formatting or customized per API call.:ex_moneyagain uses:cldrto 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.
slouchpie
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
:cldrdeps? Look at:money
something like that?
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








