In my previous job, we had a mid-sized team of ~34 software engineers and Kotlin worked like a charm. We set common standards and practices early on and it paid off. The lone wolves will exist regardless of the programming language. I've seen them in different flavors: Ruby, Elixir, PHP, JS, Python, Perl, Java, Kotlin, and etecetera throughout my career. It's a matter of team dynamics.
Anyway, I'm not a Kotlin die-hard but I found it quite fun to code in the language. IMHO, it has a gentle learning curve and the community has plenty of great libraries (e.g., Ktor, Koin).
Nevertheless, I think I leaned too much on using the syntactic sugar of the language when writing the docs and the introductory article. But by no means users are bound to this way of coding.
I think it helps to have the inputs and outputs of the system fully representing a "money" (i.e., a monetary amount + its currency code in places like API resources, events, and so on). This way you can internationalize or support multi-currency processing if that's the case. That's (if I remember correctly) what the payment card services companies (e.g., Mastercard, Visa) do by default in their message exchanges when calling the issuer for transaction confirmation.
The currency exchange support is way simpler than this. The library only provides a method that will calculate the monetary amount given another Money object as the rate:
val amount = 1 money "USD" // USD 1.00
val rate = 5.4905 money "BRL" // BRL 5.4905
amount exchange rate // BRL 5.49
It's up to implementers to hook up in other datasets and to consume the rates. Exchange rates datasets differ from country to country and some foreign exchange companies offer short-term contracts to hold a transaction at a given rate (sort of "guaranteed rate/price"). I don't see myself supporting this use case.
Nevertheless, Java Money (Moneta) has this feature. Never used it so, I don't know how it works.
I think it makes sense that this feature would not be planned in your library - as I understand, its goal is to support developers to write better money-related logic, which is sometimes related but different from simulating as accurately as possible.
I just noticed a potential misuse of your API: Transitve relationships: "A" = 2.0000 "B", and "B" = 3.0000 "C", then implicitely, "A" = 6.0000 "C". Can the user now define "A" = 7.0000 "C"?
That would be wrong - but not trivial to prevent, and practically speaking, it is okay I think.
Thank you for your time and for this exchange, wish you good success and fun with kotlin money! :)
Anyway, I'm not a Kotlin die-hard but I found it quite fun to code in the language. IMHO, it has a gentle learning curve and the community has plenty of great libraries (e.g., Ktor, Koin).
Nevertheless, I think I leaned too much on using the syntactic sugar of the language when writing the docs and the introductory article. But by no means users are bound to this way of coding.