wojtekmach
I’m happy to announce the plans for the next major version of Decimal: v2.0.0.
The primary reason for the next major release is a need for a breaking change. Elixir v1.10 ships with Improvements to sort-based APIs in Enum using a compare/2 returning :lt | :eq | :gt that a module can implement. However, there already exists a Decimal.compare/2 function with different return values, and so the function will be adjusted in Decimal v2.0.0.
Creating a new major release is also an opportunity to further clean up the API. For example, Decimal.parse/1 will be changed to behave like the Integer.parse/1 and Float.parse/1 counterparts. Other functions have been slightly changed and/or renamed to have a more idiomatic Elixir interface. Finally, the next major release will drop deprecated functionality and will require more recent Elixir versions.
Before shipping v2.0.0, we plan to have v1.9.0, which will be a backwards-compatible release that works on Elixir v1.0 and has deprecation warnings that should ease the transition.
Today we’re also shipping release candidates: v1.9.0-rc.0 and v2.0.0-rc.0. See the changelongs for more information:
- CHANGELOG for v1.9
- CHANGELOG for v2.0 (master)
Happy hacking!
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #ai
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
Sounds nice!
Have you thought about going to a Record based backend instead of a Struct? I’ve written a Decimal clone (for the functions I needed for a very limited purpose) and it benchmarked over 5 times (~5.68 average times faster for my use-case) faster than Decimal. It was identical code to Decimal (copy/pasted) other than using records instead of Structs.
wojtekmach
We haven’t discussed this. That might be too big of a leap if that makes sense, for example we’d no longer have protocols. But your results are definitely interesting, can you share library and benchmark code?
michallepicki
We will need protocols for Records for Elixir 2.0
josevalim
Before Elixir v1.0, we had protocols for Records and there were many issues. For example, is
{:name, "hello"}a record or not? Checking all tuples for potentially being a record was too expensive and it had too many false positives, meaning we would call the implementation code for something that would not be a record and then it would fail. That’s one of the reasons why we introduced structs in the first place.I am honestly skeptical this would be case. Records are not 5x faster than structs even on regular operationss, so once it gets diluted with the operations done by Decimal, I really don’t expect a 5 times improvement.
Sanjibukai
Hi,
Sorry if I’m introducing off-topic but what’s the purpose of this library? I saw the post on the forum homepage and was curious.
Is it just for decimal number formatting purpose?
Or is it even related to computation precision? If so why? Does elixir is lacking type for precision calculation (e.g. like using Float in Ruby for currency operations)?
NobbZ
Elixir does not have a native fixed point precision type,
decimalfills this gap.As far as I remember, this is as frowned in the ruby community as it is here…
Sanjibukai
Yes.. And so, I just noticed that I completely missed the fact that Elixir guides doesn’t even mention working with decimals for precision computation..
In the meantime I just discovered (while searching on the forum about how people are dealing with currencies) ex_money which seems to depend indeed on the
decimallibrary.. So I bet thatex_moneydoesn’t simply consider values as integer in cents..Anyway I’m interested to learn more on the subject.. If you have any resource (like blogposts etc.) I’ll be happy to read them..
tmbb
That might be why @OvermindDL1 sees such dramatic improvements
kip
Definitely ex_money uses
Decimalfor representing money amounts both in Elixir and the the database (I’m the author)José has always been clear in his intent to keep Elixir as a language small and to consider libraries as first class citizens in the ecosystem.
Decimalis definitely the ‘goto’ package for this purpose.josevalim
My point is that records are not 5 times faster than structs even when you are only performing records and structs operations, so when you increase the baseline by adding decimal operations as well, it is even more unlikely to get such a number.