Fast compile times. Downloads precompiled NIF by default.
Simple to use, minimal configuration, no backends.
Implements:
BCP-47 handling
Number
List
Temporal (DateTime, NaiveDateTime, Date, Time)
Relative Temporal
Currency formatting
Backed by the proven icu4x library
Already used heavily in production
Otherwise a very boring library
Some caveats:
Limited set of functionality, not as comprehensive as the cldr set of Elixir libraries.
Contributions are very welcome if you need more icu4x functionality exposed.
Uses a NIF, which may not be something you want.
NIF library is relatively heavy, it contains a lot of locale data.
icu4x is already optimized rather heavily for embedded use cases, you have loads of options to reduce library size by selecting only the data you require. Contributions are very welcome to make the icu elixir library more customizable for embedded users as well!
I think both libraries have value, would be cool to have benchmarks of both so people have more data points for which and when they should choose one or the other. But also both suffer the same pain that not all data is exposed and need continuous maintenance and contributions.
I am unsure, it certainly has some advantages around compile time and not having to implement a ton of the algorithms.
On the other hand it does use a NIF, which I know some people have a high threshold for using in production.
icu4x is also not fully feature-complete. There are probably a few things which are not present in icu4x at all which ex_cldr has. As an example, when implementing it for our use case I had to get some currency stuff exposed from upstream icu4x which we needed.
I’m thinking the nif and lib, unless that is what you’re generating. And also you mentioned you had to make changes to icux itself.
I do believe that we can make ex_cldr compile a lot faster, especially by leveraging persistent_term. Anyway I believe that runtime behaviour is more interesting.
Ah if you mean that code need to be written in the library to expose this stuff then this is true. I would be curious to hear what you think the alternative here would be through.
If ex_cldr compilation can be made a lot faster then that is great news! This is one of the main pain points which made us write this library.
My comment on the generation was directed at Kip’s question if icux would be a better foundation to build on, I disagree as both solutions faces similar constraints with regards to maintaining and data exposure.
So it does do make it easier. The two approaches have similar value with different trade offs.
Whats great about ex_cldr is that it’s all in Elixir and if we can it should be used as a target for making the BEAM compiler faster.
The upcoming Localize (ex_cldr 3.0) will compile much much faster. The current bottleneck is the compiler phase that deals with multiple functions heads. Its gets very very slow when there are many many function heads - and thats relied upon heavily in the current implementation. The new implementation is runtime only (no compile time config), uses persistent_term for data storage (not compiled artifacts - with a couple of exceptions).
