hckrnws

Cool stuff!

The use of infix functions reads a bit weird to me.

If I were to design an API like this in Kotlin, I think I would have gone for regular extensions for many cases and perhaps extension properties, think as such:

    val fiveBucks = 5.usd
    val fiveBucks = 5.money("USD")
    val tenPercent = 10.percent

Nothing is preventing you from using it this way ? Infix functions are just syntactic sugar, some prefer it, some don't, but there's zero downsides to it (aside from your coworkers abusing it.) 5 money "USD" is literally the exact same thing as 5.money("USD"), and Int.usd = this.money("USD")

+ and - are already overloaded (see val subtotal = price + shipping), increase/decreaseBy are for operating over percentages (and could be written as subtotal * (1 - discount), which is much less clear). As the other comment say, it has an actual, real life meaning that people understand clearly. Your price increased by 10 percent. the By convention is also already present in the Kotlin stdlib, although it's more for grouping operations, numeric operations are taking the Of suffix now (sumBy has been deprecated in favor of sumOf, increaseBy could become increaseOf without any loss of clarity)

This does a better job of showing an uneasy feeling I have about Kotlin than anything I could say.

- The infix is weird and footgun-y.

- Extension methods on int/double serving as constructors smells funny.

- Using infix operators as constructors but not using infix operators for addition/subtraction smells funny.

In general, at least in a corporate environment switching off Java for Android, I found Kotlin a distracting step sideways.

Code reviews tended to involve a lot of bikeshedding over how to make it Kotlin-y, and there's a sort of "why not?" approach to language features that creates much room for the bikeshedding.

It left me feeling like we were unconciously choosing to have the same arguments C++ programmers had in 1990, all over again. Except it was even more destructive, because those arguments were centered, and conflated with "proper" coding in the fancy new language.

I'm not against new and shiny: I was the first to use Kotlin in the org., and I dove right into Swift. There's something alarming with this transition.

I'm heartened by starting to see some debate in Android dev communities about whether Kotlin/Compose were a bridge to nowhere that shouldn't have been a focus for years.

You can bikeshed in any language. Kotlin introduced a lot of optional syntactic sugar so that Java devs could choose their level of comfort with the language features. I don't really see this as a problem unless your devs are prone to this sort of bikeshedding (see: your use of "smells funny"). I've used kotlin for Android since right before it was officially supported and there has been almost no downside other than the occasional hiccup with Java/Kotlin nullability interop

Hear hear, agree whole heartedly.

Minor nit: bike shedding refers to, in the original, arguing about the color of the paint on the shed.

It follows that not all discussion is bike shedding.

In this instance, the references to C++ allude to a common best practice for programmers of avoiding custom operators, which goes far beyond an aesthetic, i.e. style, i.e. color of paint on the bike shed difference. There are engineering consequences. This also applies across languages, I'm familiar with it only from trodding the same path you are, through Swift.

Bike shedding bike shedding is indeed possible, so I won't suggest an umabiguous definition. :)

The bike shedding reference in OP is to the different flavors, but equivalent, syntactic sugar that you mention. This uses the new shiny. But this creates toxic baggage, because among other things, because to a naive implementer, there is no solid engineering reason to e.g. avoid custom operators, it's just a scarred C++ graybeard enforcing their opinion :)

> so that Java devs could choose their level of comfort with the language features

and thus complicating teamwork because there is no "right" way

kotlin is great for the lone cowboy. not so much for teams.

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.

No, not in every language like in Kotlin.

I’ve never seen this amount of bikeshedding like in Kotlin. It’s as if whole identity of Kotlin developer is based on “do it differently from Java” which is super ironic for people who use JVM language.

I think that's more an effect of the language being new to you, and the company coding culture not having developed around it yet, than a problem with the language. Kotlin has warts, sure, but we have been using it for seven years now, and while we did have some bikeshedding in the beginning, it is virtually absent from our code reviews now. The language didn't change (well, it got even more features), but we did.

I have used Kotlin professionally for a couple-few years; and, in my experience, infix operations are a choice and you don't have to use them. - in fact, I don't think any bit of code in anything I've used uses infix operations, this is my first time seeing them in Kotlin in the wild.

For example, I haven't used them even once.

That said, I, personally, have done almost no Android programming in Kotlin, so perhaps I'm missing the main environment where such things are done? For me, Kotlin has mostly been an aggressive amount of syntactic sugar to make Java a nice experience?

And most of the DSL-style code that I write uses function pointers as the last parameter, so I can do doTheThing(parameters) { anonymous function } and that's about it?

I'm sorry that the organization you work with has aggressive bikeshedding. Perhaps this is something your organization, in general, could have a conversation about?

I agree, you nailed it. Operators are something that feels like using the new shiny but are repeating well-trodden mistakes that are well-understand in languages ranging in age from C++ to Swift.

I was referring to in-fix, like can be found in Kotlin and Ruby, not necessarily operator overloads. I've found pretty usable operator overloading, in appropriate contexts, like adding two lists meaning append.

I hear what you are saying but there is the other side. Perhaps the opinion/feeling you are having is related to getting older.

We've learned a lot about what works and what doesn't in programming languages. Goto considered harmful and all that kind of stuff. If you want to get a Lisp/Haskell fanatic really going point out how so many of the features in those languages have finally made their way into mainstream languages (lambdas, etc.).

What we don't often consider are all of the language features that didn't make it.

This process didn't stop sometime in the past. It is happening right now. That feeling of unease may not be an indication of the quality of the features you are considering. It may largely be uncertainty about what features will or will not stand the test of time.

Perhaps as we get older, we want languages that have all of the good stuff we've learned from the past and none of the experimental stuff that we aren't too sure about yet. That might be because we are starting to notice that we won't have enough time left in our remaining days to sort all the new toys into the good/bad bin.

Stirring call to action for creativity, but it is unclear how a comment that boils down to "new things might be good" applies in this context.

as OP refers to, custom operators are considered harmful in languages ranging from C++ to Swift. It's a great contemporary example of goto.

I suppose the more poetic: "don't speak too soon, for the wheel's still in spin" is another way to state it. It isn't "new things might be good" it is more a reminder that your self-described feeling of unease may say more about you than it does about the language feature under question.

I've seen some horrors in my time due to custom operators. I've also suffered through some horrors when they are missing and would clearly be appropriate. They seem appropriate for linear algebra libraries for example. Not everyone agrees, obviously.

As an aside, I have been watching a lot of YouTube videos of people programming C. I notice that goto shows up very frequently, especially in modern C. Usually it is a label at the end of a function to manage resource cleanup before returning, almost like a manual `defer`. Sometimes it is to break out of nested loops. I mean, I've always taken Dijkstra's point to be that long jumping out of a procedural boundary was the real problem, not the keyword "goto". And built-in language features that obviate the need to use goto even for the reasonable use cases are my preference.

I feel the same about custom infix operators. I too share an unease about them. But I have to admit they feel right sometimes. I admit I don't have enough information on their use in this kind of case to know if it is one of the good ones or one of the bad ones.

> The infix is weird and footgun-y.

If it's a foot gun, then I'm not seeing how the gun is loaded?

> Extension methods on int/double serving as constructors smells funny.

It doesn't feel meaningfully different from the static factory pattern in traditional Java, where 10.percent() would be something like MoneyUtils.createPercent() or Percent.create() with several overloads. Under the hood, that is essentially what is happening. Only downside I can see is that it muddies what truly belongs to the class, but that's true of any extension function and Kotlin is intended to be used with IDEA's introspection anyway.

The Kotlin standard library has lots of extension functions that construct new objects.

It also reminds me of Ruby, which perhaps you're also not a fan of and that's OK.

`decreaseBy` is a multiplication and subtraction combined, map naturally to commerce domain, and is more complex than plain addition / subtraction.

> overloading `plus` and `minus`

Perhaps I'm misunderstanding your idea, but what about

  val total = price + 10.percent * 2

I suppose that depends on how you implement `times` for the `Percent`-class. One way would be to say that 10% * 2 = 20%, making this expression evaluate to 12, in accordance with Kotlin operator precedence [1].

It's possible to avoid making this decision altogether by not implementing `times` for `Percent`, making the user have to be more explicit about what they actually want to happen - for example, requiring them to add parenthesis to arrive at 22:

    val total = (price + 10.percent) * 2

    val total = price + (10 * 2).percent

>val total = price + 10.percent * 2

If the price is 10, I would expect total to be 10,2.

(price + 10.percent) * 2 would be 22.

I don't see any way to get 12.

How do you get 10.2? I can only think of two (reasonable) ways to think about this:

    (price + 10.percent) * 2 = (10 + 1) * 2 = 11 * 2 = 22

    price + (10.percent * 2) = 10 + 20.percent = 10 + 2 = 12

To get the 10.2 you should use the standard tricks to use % in math. For example in a two equations system [1].

  x + y = 100
  90% x + 80% y = 84

  x + y = 100
  90/100 x + 80/100 y = 84

So in a math class, when you see 20% you translate it to .2, and 10+20% means 10.2. But in a calculator and in the OP project the % button is magic and and 10+20% means 12.

[1] You have to buy two item that in total cost $100, but today there is a 10% discount in one and a 20% discount in the other so you pay only $84. ¿How much is each item?

Percentages are incommensurable with most things, including other percentages in the general case. They are percentages _of something_ and in general the only way you can do addition, subtraction, or comparison is to identify the referent and multiply it out first (the special case is when the other value involved is another percentage with the same referent). So in math class, when you see 20%, you translate it to ".2 _times something_", which is not a value that can be added to 10. You have to figure out what to multiply it by first. In the case of 10+20%, it would be reasonable to assume 20% of 10, which is how you get 12. It would also be reasonable to ask "20% of what?" 10.2 is 10 + 20% of 1, which requires an explanation of how that 1 got involved.

price + (10.percent * 2) looks like 12: If 10.percent = 1, 1*2 = 2. 10 + 2 = 12.

Under the usual rules of operator precedence, that would be the expected answer (multiplication having higher precedence than addition).

How does computer know it's 10% of 10? Unless specified, 10% is 0.1 Or am I an idiot and missing something here

If you oveload "+" to mean whatever-you-want, it's possible. Using bad python [1], it's something like:

  def sum(x,y):
    if is_number(x) and is_number(y):
      return x + y
    elif is_number(x) and is_percent(y):
      return x * (1 + y.value/100)
    else:
      raise fatal_error

[1] Sorry, my main current language is Racket, but I thought that python-like is easier to read for most people, in spite people that likes python can find like 10 error in 7 LOC.

First, congrats on the library and thank you for sharing it!

1) A hint about potential prior art: F# (and/or C#?) have a first-class unit system (physical units I think), which sounds a bit similar to monetary calculations. However, physical unit are easier to model than monetary unit I think.

2) Currently, I am building something tangentially related in Rust: A backtester (test trading strategies on historical and/or simulated data) with focus on accuracy. So one thing I included already is that Assets (like etfs) are valued in a currency.

If I may be so bold: How would you approach these questions / where could I read more about that? 1) When simulating, can I always assume that the exchange will work? (For assets, that is not always the case, sometimes one has to wait a bit until there is a buyer, or there might not be a buyer at all) 2) Is there public domain data in exchange rates? 3) If I have to choose, which exchange rate should I pick? The lower one, higher? What would make the most sense in the context of trading etfs, stocks, options, crypto etc.? 4) How to approach rounding, is there a best practise? 5) I assume it is best to immediately substract taxes in every transaction, even if they are formally defined annually, right? 6) Would you model inflation? I currently plan to ignore it and present it at the very end: "Your portfolio has a final value of X.X ¥. Adjusted for inflation, that would be Y.Y ¥ today (2024-10-08)."

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.

Thank you for your insights!

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! :)

Exchange rates are often not perfectly aligned, even if for a short periods of time. This is where arbitrage comes into play and levels the market.

With that we can go back to the example:

"A" = 2.0000 "B"

"B" = 3.0000 "C" -> "A" = 6.0000 "C"

"A" = 7.0000 "C"

If you notice this happening in the real world, you have the opportunity to:

1. buy 7 "C" with 1 "A"

2. buy 2 "B" with 6 "C"

3. buy 1 "A" with 2 "B"

4. keep 1 "A" profit

But it's rarely that simple and it often involves 3 or more currencies

I like the support for custom currencies, as that is an edge case that often pops up.

On the other hand, be careful about tying the symbol to the currency, as symbols are locale specific. For example, the symbol for USD is $ in eu-US but US$ in en-CA and en-AU (Canada and Australia), and then $US in French locales.

https://cldr.unicode.org/ is the magical dataset behind most good implementations that deal with currency display. Updated twice a year, available in JSON, providing currency symbols and formatting rules for all locales, as well as country => currency mappings and other useful information.

Disclaimer: I maintain a Go solution in this problem space: https://github.com/bojanz/currency

I know this is a mere quibble as a rider on a helpful post, but a disclosure is not a disclaimer.

Disclaimers separate you from the comment, examples:

> Disclaimer: I am not a lawyer and this is not legal advice

> [says things about $company] Disclaimer: I don't work for $company, I heard this from someone who does but I can't link to a primary source

Disclosures are additional information which you think it's proper to add, to be open about your interest or stake in the topic:

> Disclosure: I wrote a similar library

> [replies to thing about $company] Disclosure: I used to work for $company

Disclaimer is more often used for humblebrag, not to disclose any information.

Right, indeed!

I'm curious, is there a standard practice of library developers in a certain space collaborating across languages, sharing issues and corner cases and solutions? Is this a common practice with a name? Or is it up to you to look through issues and release notes on projects in the same space to glean useful information?

Not sure there’s a particular name beyond ‘working group’ or ‘technical committee’.

CLDR a really interesting one though, their list of users is quite something too.

I'll introduce l10n support in a future release. My starting point was to make currency names and symbols unaware of the locale as I embedded cryptocurrency data in the mix.

Anyway, the library uses the CLDR dataset through ICU: https://github.com/eriksencosta/money/blob/trunk/docs/append...

It's kind of strange that spreadsheet languages don't support money well. Using spreadsheets for escalator style automation is actually quite good and would really be amazing in a language that took typing seriously.

I think there's a good reason for it to be part of a library. The problem with currencies is much like dates: they're a social construct, and change more than most of the social constructs we embed in programming languages.

I don't want to update my interpreter or compiler because Turkey changed their rules of daylight savings time, or Ethereum becomes popular.

Oh, this reminds me of my first job out of college at a Swiss bank. Apparently every time a currency conversion was done in a particular model, there was a routine that translated back and forth between the pre-Euro currency and Euro at the conversion rate. So a USD-EUR transaction with a party in France would be run as USD-FRF --> FRF-EUR. All in COBOL. As a result, every so often, you'd get a slightly different result running a USD-EUR trade with a party in France versus e.g. Germany or the U.K.

So what happened when those discrepancies arose?

They became the basis for the plot of Superman III

> what happened when those discrepancies arose?

They were just passed along.

Yes, and sometimes the context is not just social but legal or contractual, e.g. rounding currency.

Yes, and rounding currency is just something that is always handled, as is the number of places that you take a currency out to - for example, gas is often priced at thousandths of a dollar rather than hundreds but presented to the customer in hundredths at the end. Or Yen in most cases does not have a decimal point, except that the places where you round or don't round can be consequential in large enough quantities.

These are largely things that can be handled by a library, but if it's in the language you best not get it wrong because it's so much harder to change!

From my perspective those are tenths of a cent. Stripe has integer values for cents.

Am I wrong here?

https://stackoverflow.com/questions/35326710/stripe-currency...

There's two problems with currencies:

1. So many languages don't have a native "decimal" type to build off of, so somewhere in the data's lifecycle, a "1.75" turns into "1.7499999999997".

2. The rules around exchange rates, number of decimals, coding and symbols.

The first problem should be solved as a first-class language feature. This will discourage hacks with a "fixed point" type, where you store integer "175 cents" instead of decimal "$1.75"-- inviting huge confusion if the currency ever drops or restructures its minor unit, and supports non-money use cases where floating point inaccuracy is risky.

Item 2 makes more sense as a library. You can record that there's a 1000:1 ratio between pre-1998 and current roubles, that the symbol for the Baht will inevitably confuse Bitcoin enthusiasts, and that the Korean won no longer has any decimal places, in dynamic fields.

This. But more than being changeable they (time and money) are supra-logical or trans-rational. In other words, computers are limited to what can be modeled or calculated with the one logical operation (it has lots of names, I like "Quine dagger") but these phenomenon are not.

You could say the same of Unicode, though. Some cultural abstractions become increasingly rigid because they’re embedded in computer systems everywhere.

I couldn't agree more as someone who has been using more spreadsheets than actually coding in the last 10 years.

Spreadsheets, browsers, databases.

Everything is decided to be an 'abstraction' and it's someone else down the line that has to be concerned. Over the last 30 years of starting as a developer I've really lost faith that the majority are actually concerned with solving anything vs just indulging conceptual whims.

> Spreadsheets, browsers, databases.

I think you're mixing up stuff that's unrelated to your concern.

The concerns you're expressing only apply to operations and financial transactions. That's not handled by spreadsheets, browsers, or databases. In fact, the primary concern of a browser is to provide views over data fed by servers.

In addition, it sounds like you're confusing minor conveniences with something being somehow broken by design. The reason why no one bothered to standardize a money type is the fact that there isn't a technical requirements for it at all.

Nice! Reminds me of the ergonomics of Rebol's money type:

https://www.rebol.com/docs/core23/rebolcore-16.html#section-...

> $100 + 11 $111.00

> $10 / .50 $20.00

In general, Rebol's type system was very expressive. Would love to see more libraries like this provide that type of experience.

This is great!

What I want more than a library is an exhaustive test suite for all of the edge cases segmented by currency or finance authority.

Tangentially, I also often think about super-strict typing. I know people mention some languages that already do this sort of thing (Units of Measure in F# was talked about). It seems silly to me that so many low level programming languages still use uint64, size_t, or char equivalents for the vast majority of the code. Why not `celsius` vs `farenheit`? Or `meters` vs `feet`. That would stop a lot of possible errors. And even more so, if the language supported things like (2 feet * 2 feet) = (4 square feet). Or (10 meters / 5 seconds = 2 m/s).

My only complaint is that there seems to be too much infix. Why not just do 50.btc, 25.3.usd This would keep it inline with the time API doing 20.seconds Also percentages could be standard library if you ask me but would probably also need to be 2.3.percent.

Looks cool, always happy to see Kotlin love!

What do you think of this? https://github.com/eriksencosta/money/blob/enum-percentage-s...

It is a (quick) spike solution, but I've implemented the currency codes as enums and added support for 20.percent.

Not so sure about supporting 50.btc and 25.3.usd. I need to check if doing so would affect code completion.

Thanks for commenting. I'm still learning Kotlin and I overlooked the usage of get() with vals. This will be the next syntactic sugar into the mix. I think it makes sense.

When I was designing the API, I created methods like toUSD() and toEUR(). But with 306+ circulating/tender currencies and 2000+ cryptocurrencies, I thought it could lead to a bad experience when using code completion.

I have questions about some edge cases I've encountered in dealing with money.

- Let's say I load two money values from a database. Value A is 1 USD and value B is 1 BTC. If I try to add them together, what happens? (I would expect a runtime exception. In fact, I would hope for a runtime exception, because the operation usually indicates a programming error.)

- If I divide $2.00 by 3, do I get $0.66 or $0.67? If I want to specify the rounding rule, is there a simple way to do it? I see there's support for allocation by percentage, but sometimes the allocation rules are more complex and I need to be able to specify the rounding rule.

- Does this library help parse user input? When parsing user input, what happens to extra digits? Does "0.015" get interpreted as $0.01 or $0.02?

Edit: one more question. Sometimes people bend the rules on the number of digits; for example, gas stations may charge $3.599 per gallon. Can the library deal with that or would I have to convert to decimal, multiply, and then convert back to money?

Thanks for the questions. Answers:

1. You get an exception

2. You may specify the rounding rule: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

3. It has some parsing capabilities. The extra digit is kept, rounding is only applied when doing an operation with the Money object

4. Same as 2

Does this library handle rounding rules [0]? In many countries, prices are rounded to the nearest 5 cent, but the rules can often be elaborate. It looks like the allocation interface might support this, but at the moment I didn't find any mention of it without digging into the docs themselves.

[0] https://en.wikipedia.org/wiki/Cash_rounding

I think one common feature of those rounding procedures is that they are only done for cash payments, rather than plastic, so rather than representing a monetary value, it would have to represent a payment specifically. (With knowledge of payment method and time of transaction since a lot of these rules had a start date.) Possibly a good library to extend off of this!

I'm working on a Clojure library for working with money [0] that handles specific rounding rules by passing a custom rounding function to the round function, allowing you to specify different rules as needed.

There's an example for the Swiss Franc in the README (the code is here [1]).

[0] https://github.com/sernamar/dinero

[1] https://github.com/sernamar/dinero/blob/main/src/dinero/roun...

This is something I am aware but there is no support for this rounding scheme at the moment.

Wait, how do you round? A fixed table from currency to minimum increment? You’re not about to find 1/100-Yen coins, for example.

You are not going to find 1 or 2 eurocents anymore either, but it is still a valid amount. You can pay that electronically, but not in cash.

So rounding for cash is a different problem that rounding money in general.

>You are not going to find 1 or 2 eurocents anymore either

You may want to tell that to my wallet, as well as the payments I make with them. There's a cool 37 billion coins outside in the wild, so you're going to find them rather easily throughout Europe, even if your own country has stopped using them.

Huh? 1 and 2 eurocents have not been deprecated, afaik only Finland and the Netherlands don't use them anymore...

Also Belgium, Ireland, Italy, Slovakia...

Technically, you can use them for payment, they are still valid money; but the price will be rounded to 5 cents when paying in cash and you won't get them in the other direction.

The 1 and 2 eurocent coins are still legal tender in the Netherlands, stores just have the option not to accept them and are allowed to round prices to avoid having to stock them (if communicated beforehand).

It's been years since I last saw a eurocent coin, but it's been eliminated by permitting businesses to remove the need for them, not because they're being phased out.

HALF_EVEN by default using the minor units of each currency (based on CLDR/ICU datasets). Client code can disable rounding at all.

Check for more: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

Things like gasoline can have a price that is a fraction of a cent. The ultimate price is rounded.

Canada has these guidelines: https://www.canada.ca/en/revenue-agency/programs/about-canad...

C# has a decimal type: "The decimal type is a 128-bit data type suitable for financial and monetary calculations." https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

That provides the basis for solving precision and rounding issues but for a money library you need more abstractions. The ability to assign a currency code and supply conversion rates and convert between currencies at a minimum.

Also, avoid making errors like summing different currencies.

The thing is, it doesn’t really help. A system I’m working on can have hundreds of monetary amounts in the same currency. Storing the currency against each one is an awful waste of space.

Equally the allocation trick is good, but you’ll find that the people who really care about this stuff really care about the exact algorithm you’re using and who it favours.

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.

Anyway, the allocation may be tweaked to favour where the additional/missing pennies will be allocated. You can find more at: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

That’s an application design choice, not a minimum. An alternative is to work internally in one unit and convert at format time.

We store all our financial data in Greenwich Mean Dollars.

What are you going to do about the new Moon Dollars?

Might be a minimum for a money library (not completely sure what the absolute minimum would be). It would be an application design choice to not use one and stick to general fixed point/Big Num constructs.

That is not a viable alternative.

Even though my gut reaction is to agree with you, it’s true that it is an app design decision, so in certain scenarios it might very well be a good design decision.

Shipped applications disagree with you.

It really depends on the context of the app

Sometimes you can do all calculations in a single currency and convert at reporting time. I've worked on teams where that was fine.

Sometimes... you really cannot do that.

Completely agree.

Out of curiosity, how do you deal with changing exchange rates in that case?

You never want to be lossy with user inputs. Save what they told you and then convert for internal logic.

The OP just described a language feature where you want to multiply euros with usd one place and yen and dinar in another.

You don’t need to do that which is why a decimal or 64 bit int is a fine language approach.

it depends, if it was a currency exchange, it'll be labeled in one of 3 ways, either average rate per unit, absolute, or it'll be a reference to a MSSQL table containing exceptional spot transactions. Otherwise, a complete history of exchange rates is stored in KDB, most days you can take the average, and for small amounts on weekends or days the exchange is closed you can just interpolate, there's also a half dozen XLSXs full of certain exceptional days, so you'll have to check that you're not on one of those lists. Then if you're not dealing with USD->X or CAD->USD->X things start to get hairy.

Nice. Looks like it satisfies all the requirements detailed here [0]. Also, good discussion of the major difficulty dealing with money here [1].

[0] https://cs-syd.eu/posts/2022-08-22-how-to-deal-with-money-in...

[1] https://www.reddit.com/r/java/comments/wmqv3q/standards_for_...

Java has JSR 354 for money [1]. There is also a reference implementation [2]. So there is official support for money in Java.

[1] https://jcp.org/en/jsr/detail?id=354 [2] https://javamoney.github.io/

Would be cool to hook this up as a manifold unit[1]. This way you could write code like:

Money ask = 2.1M USD;

What I don't see with the Java JSR is how exchange rate services are integrated (if at all?). In the best of worlds, as with manifold's units I could write.

Money deposit = 300 USD + 500 EUR;

Where internally the deposit automatically maintains the amounts separately and uses exchange rates only for spot display/calc, transfer, etc.

1. https://github.com/manifold-systems/manifold/tree/master/man...

> Money ask = 2.1M USD;

Feels like it should be

  Money<USD> ask = 2.1M USD;

Generally, the idea is that there is no incompatibility between units. Money is a bit exotic given its abstract nature wrt units / exchange rates.

For instance, physical dimensions store values as SI units, regardless of supplied unit, but retain the supplied unit type as a display hint.

Here, the Length dimension illustrates working with amounts of any unit.

Length orbit = 250 mi;

Length moon = 238000 km;

Length landing = moon + orbit;

display(landing); // prints 148,136.344 mi

display(landing.to(km)); // prints 238,402.336 km

// where

display(landing.to(mi) == landing.to(km)); // prints true

// perhaps a better example

Rate rate = 1.41 km/s;

Time duration = 76 hours;

Length distance = rate * duration;

// make your own unit constants

RateUnit kps = km/s;

rate = 1.41 kps;

You can play with the manifold-science[1] project, it implements the complete SI physical dimensions and many derived dimensions along with comprehensive operator overloading[2] support etc. to make working with and reading code using quantities more productive in Java.

1. https://github.com/manifold-systems/manifold/tree/master/man...

2. https://github.com/manifold-systems/manifold/tree/master/man...

The JSR 354 API can provide access to exchange rate services via the ExchangeRateProvider interface. The reference implementation (Moneta) includes a few implementations of ExchangeRateProviders that connect to online services to look up exchange rates.

I'd like types for all the currencies.

USD rent = 2000

EUR salary = 6000.53

USD disposableIncome = salary - rent

Then:

disposableIncome.toDecimal()

disposableIncome.toInteger()

disposableIncome.toString()

USD interest = disposableIncome.compoundInterest(startDate, endDate, apy)

USD tip = billTotal.tip(percentage)

USD and EUR would inherit from Money

Not sure how to implement it, might be a JVM magic thing.

What you want is Money, currency is a _unit_ type of a Money quantity, just as meter is a unit type of Length.

Money cost = 25M USD;

cost += 12M EUR;

display(cost.to(EUR));

I don't think this makes sense? You need to specify an exchange rate somewhere.

> just as meter is a unit type of Length

The difference is that length units are fixed, but exchange rates are constantly changing.

> You need to specify an exchange rate somewhere.

Right. As I mentioned earlier exchange rate services would need to be integrated into the API.

Also, exchange rate services would not be needed until a conversion is necessary. For instance, when adding money of different currencies internally the Money type maintains currencies separately, subtotals for USD, EUR, etc. are managed. If at a later time the sum of Money should be displayed, deposited, etc. as a single currency, only then is an exchange service involved.

Except Kotlin is a multiplatform language now thanks to Jetbrains efforts (kmp project), it's not anymore intertwined with JVM.

Using Java library will limit your program only to jvm platform. Using a kotlin library like this one (given it's written in pure kotlin and doesn't uses any jvm platforms specifics) will allow you to build it to whatever target kmp supports (macosx, ios, android, js, mingw...)

> to build it to whatever target kmp supports (macosx, ios, android, js, mingw...)

Plenty of languages (also Java with Graal, TeaVM, J2CL, etc.) can also target these platforms.

But as with all these languages targeting these platforms (including Kotlin) you are going to have to call platform specific API if you want to do anything useful. There are also platforms specific limitations which means certain stuff which you can do in the language doesn't work on those platforms.

Not yet to Android (in the case of the library). Need to revamp some internal things.

It will never not be funny to me how Java language designs have such a hatred for operator overloading yet will happily accept .multiply(2).add(something) as a substitute.

How does it compare to the Java money API (https://jcp.org/en/jsr/detail?id=354) and the related Kotlin DSL in https://github.com/hiddewie/money-kotlin/?tab=readme-ov-file...?

Another library in this space is Eric Evans' (of DDD fame) Time & Money library https://timeandmoney.sourceforge.net/.

I'm surprised nobody has mentioned Joda Money yet:

https://www.joda.org/joda-money/

From the same person that brought us Joda Time (ie, what the java time API was based on). I've used Joda Money a lot and it's great.

Honestly I prefer APIs that look like APIs and I think this trend towards inventing DSLs is a bad one. Rails works because there's a critical mass of people who have adopted what is essentially a whole new language on top of Ruby. A money library doesn't warrant a new language, it's unnecessary cognitive load. This new money library would look fine with simple constructors and method calls.

Joda is impressive and has great performance.

The examples were written using the infix notation but you can just use regular method calls. For example:

val price = Money.of(100, "USD")

val shipping = Money.of(5, "USD")

val subtotal = price.plus(shipping)

val discount = Percentage.of(10)

val total = subtotal.decreaseBy(discount)

total.allocate(2)

total.allocate(60.percent(), 40.percent())

I personally went with Joda money versus the Java money API mentioned above. Our needs are a bit simpler and the Joda Money API is a bit simpler to understand. Our app only deals in USD so I wrote a small utility class to help initialize Money instances so devs don't have to write:

    Money.of(CurrencyUnit.USD, amount)

I'm very grateful so far by the comments. I've learned a lot and it will help me on the next iterations of the library.

Nice library!

Manipulating money is probably trickiest thing since time was invented. Library looks very usable.

I have to ask though:

> val transactionFee = 1.25.percent() // 1.5%

How is it 1.5?

Oh sorry, that's a typo. Thanks for pointing out!

except for manipulating time, i'd say

Kotlin has the problem of "I had N problems, so I think I can create 1 new solution, now I have N+1 problems" (obligatory https://xkcd.com/927/).

The 'money/percent/usd' are almost like new keywords - which to me seems bad. Why not a formatter or another tool that simplifies but doesn't make it too clever or worse, hard to read.

Kotlin is really cool and arguably better than Java. But the language is very hard to read ('easy' to write). And with so many different ways of doing a single thing (and many of them exist to support Java, I understand) plus new 'macro-like' things expanding the language automagically makes it very hard to grasp.

I hope I am not the only one with this same feeling...

I think one clear tradeoff that Kotlin - arguably intentionally - makes, is that it's harder to work with than other languages without the use of an IDE. It is after all made by an IDE developer.

It's also quite a bit more liberal in introducing new features than Java is, and with a larger feature surface there's more potential for misuse.

On balance, I think using Kotlin over Java is worth it, though.

Same feeling. It’s rather painful to read Kotlin code because of so many features that imho are not really that needed… and every developer wants to use them all.

When we first started using Kotlin, it was like you said. The devs were eager to try all the new possibilites and apply them wherever possible. Resulting in sometimes needlessly complicated solutions. After the initial excitement faded, everyone is now much more conservative. Kotlin is still very much appreciated by pretty much everyone. But now sometimes I even have to remind a coworker when there's a language feature or a built-in collection function that might help them.

Kotlin has a few new features (infix operations for instance) but most of its feature set is stuff other languages have had for years, sometimes decades, written down a little bit differently. There's no functional difference between lambdas in Kotlin and Java, class extensions have been in C# for ages, and operator overloading has been a thing for decades.

Most of the resistence to Kotlin I see seems to come down to "I don't know the syntax and that makes it hard for me to understand the language" or "this isn't like the language I prefer".

Kotlin actually brings surprisingly few language features to the table, its API is just very effective at making use of the few new features it brings as opposed to the ossified languages from a few decades ago that offer new features but then decide not to make use of them in the standard library in case a programmer doesn't like using part of the language.

Criticising Kotlin for using things like infix operators or lambdas is like criticising Java for shoving classes and generics down everyone's throat. You can write Java with only minimal use of these, but you'd end up with a weird, non-standard code style for the language. There are still plenty of programmers around that despise the concept of classes or inheritance and will declare any Java/C#/C++/Javascript/Go program unreadable for making use of OOP concepts, not dissimilar to the "I don't get Kotlin" people that seem to have been tricked into believing Kotlin is supposed to look like Java.

> Kotlin is really cool and arguably better than Java. But the language is very hard to read ('easy' to write)

I had the same immediate reaction. This style of code is something the Scala community used to be in love with, and was criticized for it. The community has largely moved away from this style, so it's interesting to see history possibly repeating itself with Kotlin.

It feels so lambda and extension function heavy.

Not a mainstream language, but Ada has Annex F - Information Systems, which can be used for currency handling. [1][2]

[1] https://ada-lang.io/docs/arm/AA-F/

[2] https://www.adaic.org/resources/add_content/standards/22rm/h...

> no mainstream language has a first-class data type for representing money

Visual Basic 6 and VGA had a `Currency` type (replaced by `Decimal` in VB.NET): https://learn.microsoft.com/en-us/office/vba/language/refere...

T-SQL has `money` and `smallmoney` types: https://learn.microsoft.com/en-us/sql/t-sql/data-types/money...

...am I missing something?

> Visual Basic 6 and VGA

*VBA, sorry; typo. HN won't let me edit my posts argh.

> mainstream

;)

What could be more mainstream than VB6?

Excel macros.

The IBM 1401 mainframe (1959) optionally supported pounds/shillings/pence (£sd) arithmetic in hardware. In those days, there were 12 pence in a shilling and 20 shillings in a pound, so arithmetic with UK money was non-trivial. (This wasn't even microcode; this was literally boards full of transistors to add, subtract, multiply, divide, and format currency values.)

I love to learn more about the history of computing. Thanks.

I'm new to Kotlin. Can someone explain how this function creates a Money object incorporating the given count of them?

This looks like it's ignoring the Number and creating a new Money object (of denomination 1?)

> public infix fun Number.money(currency: String): Money = money(currency, defaultRoundingMode, null)

In Kotlin, an infix method can be called without the `.` operator, and without the parens surrounding arguments.

    100 money "USD"

    100.money("USD")

    fun money(count: Number, currency: String): Money

Thanks!

I allowed myself to be distracted by all the weird infix stuff. I was thinking "but it's not passing itself into the money constructor" but it's actually just delegating to a different-signature version of `money` _on itself_ that will use its value then.

Great see that kotlin didn't avoid all Scala's bad ideas.

It'd be easier to follow if you could provide a link to the GitHub line you're looking at, but most likely the `money` function being called is a second extension method of the Number class, which means that it implicitly gets the Number object as `this` and presumably uses it to build the Money.

https://github.com/eriksencosta/money/blob/4bef95a1d2158e308...

Yeah, that's just an infix function that provides some default parameters to this extension method:

https://github.com/eriksencosta/money/blob/4bef95a1d2158e308...

Infix functions is one of the worst features of Kotlin.

Congrats on the library, I’ll be looking into it for some nuggets of knowledge.

However, the Kotlin code looks absolutely… wrong? Strange? It just feels like a lot of magic to end up with ugly code.

This is all subjective, so my question is only this: is this how Kotlin is like in 2024?

>However, no mainstream language has a first-class data type for representing money

Parcal has a Currency type. Though, I can understand not calling it mainstream... Fun fact it's a fixed point type which is just a Int64 behind the scenes, at least in Delphi.

The currency codes could probably be inline value classes. That way, you can do

    val price = 100 money USD

Maintaining an up to date currency list is, quite frankly, hell. Your code will always, always be more up to date than said list.

This could be mitigated by making the currency interface / abstract class open to extension by the user. The common currencies would be provided by the library and any additional ones could be defined by the user.

Making currencies a concrete implementation is a terrible idea. There is no benefit to it at all, except throwing OOP into something that doesn't need it. A single Money class covers all needed cases, the difference between USD and BTC is... everything. Different smallest denominations, different formats, different everything. You don't even need concrete implementations

    private data class Money<T>(val name: String, val amount: Int) {
         operator fun <U : T> plus(other: Money<U>): Money<T> {
             return Money(name, amount + other.amount)
         }

         fun <U> plus(other: Money<U>, converter: (Money<U>) -> Money<T>): Money<T> {
              return converter(other) + this
         }
    }

    private object EUR
    private object USD

    val eur = Money<EUR>("EUR", 10)
    val usd = Money<USD>("USD", 20)

    usd + eur // error

Currencies should always be the user's responsibility to provide.

> except throwing OOP into something that doesn't need it

I feel like you're jumping to wild conclusions. All I'm suggesting is to change your code to

  private object EUR : Currency
  private object USD : Currency

  data class Money<C : Currency>(...) { ... }

You could argue the same for timezones in a date library, yet they have them. I would think a library dedicated to money will in fact be the most up to date.

Do they ? I've never once had a library that stores Europe_Paris, or Offset_Plus_7_45, they've always been stringly typed. Do you have an example of who'd be crazy enough to maintain a wrapper around tzdb?

What is up with that API? `1.25.percent()`? `1 money 'USD'`? Love the spirit of a money library, but this is a little odd.

Even as someone familiar with Kotlin, it's hard to decipher what this library is doing without syntax highlighting here. The author is using infix functions and custom extension functions on primitive types. Non-Kotlin-natives will scratch heads.

Oh no, I know how it's done, I'm just surprised by it. There are more straight forward ways of expressing the same thing without using infix functions and those extensions (e.g. `val price = USD(100)` or `val price = Money(100, 'USD')`).

This covered the API nicely but said nothing about how the amounts were internally-modeled and how rounding was dealt with. It was only mentioned.

I had an idea for a fixed-decimal class (that would also be useful for a money class) that held all inflight amounts as fractions and only did the division and float rounding when you needed to view the amount.

Neat. It seems to me like this is filling three separate gaps:

  - fixed point arithmetic
  - tagging values with units
  - localization for parsing currency names into units

The library will throw an exception if doing an operation with different currencies: https://github.com/eriksencosta/money/blob/trunk/money/src/t...

But I think I'll make it explicit in the documentation. Thanks for pointing out!

> catch at compile time

Not in this library, but I think it's possible to put the currency as a type parameter.

I wonder if this would handle small decimals.

Edge case?

I want to calculate the installments of 265 Wei (0.000000000000000265 ETH) over a period of 144 months

Banks typically use a fixed floating point of 1 integer step = 1/100 cent. Is this value configurable in your library?

Yep, it is. However, you must create a custom currency to arbitrarily define the minor units you need: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

I doubt Japanese ones do.

Yes, because partial units still have meaning when dealing with interest and taxation.

Delphi has a currency type, as does C++Builder (so, a native Currency type available in C++ with that toolchain.)

This one seems to carry units, as in, it is not a type with math for a known amount of fixed point precision that differentiates this library, but that it captures that plus the unit -- the currency, USD, EUR, etc -- that it is in.

You are right. Languages indeed have support for currencies and decimal numbers. My implementation is based on Fowler's Money pattern. The Money object is thus a value object representing a monetary amount in a given currency.

Are integers still a preferred method for working with and storing monetary amounts or can we go back to decimals now that most languages handle decimals decently? Monetary amounts pretty much always need to eventually be presented to humans so handling them as integers is quite a pain.

It isn't that common to need fractions though. Money is typically handled in integer amounts (we just divide the amounts by 100 or whatever to make it easier for humans to grok). Nobody's going to pay half a cent for a latte for example. If for some reason you do need to deal with 1/1000 of a dollar, or 1/10000 of a dollar, you can still use integers. You just need to know the scaling factor.

Your presentation layer is probably always going to need to do some manipulation of the number anyway (put a dollar sign on it, etc) so using a decimal amount just for presentation needs isn't a huge win. But it will work too.

A decimal type is sometimes orders of magnitude slower than integer do simple stuff like summing (at least in Postgres and Python).

This comes into play if you have to do aggregate functions across tens of thousands of rows and can kill performance compared to integers.

Cool! As underlying values, do you use integers, bigdecimals, or a decimalized double hack like in OpenHFT?

It uses BigDecimal. My first goal with the library was to provide a well-designed API. So to keep it simple for myself, I relied on BigDecimal for the calculations.

I think you are right, API is the most important part; internal implementation can be optimized later.

What is the double hack used in OpenHFT? I tried looking this up and came up short.

https://github.com/OpenHFT/Chronicle-Core/blob/ea/src/main/j...

(see roundN)

Be careful and use it only if you know what you are doing and understand the limitations.

I’ll byte. Perhaps you didn’t look long enough. I’m sure the answer will float by at some point.

I just had to implement the 'allocate' functionality described here, specifically with the %-based weights, and it was a pain that required careful comments to ensure was clear! Would've loved to use this instead.

It was fun writing the extra pennies distribution logic tho

It's a shame I can't travel back in time. Anyway, thanks!

Look nice. I do find the wordy operators reminiscent of Cobol. Instead of "subtotal decreaseBy discount" in Kotline I would expect either "subtotal.decreaseBy(discount)" or perhaps "subtotal * (1 - discount)".

I don't know Kotlin very well. Can it track the currencies involved at the type level, so that trying to combine (say) USD and EUR amounts in an error?

My complaint is, bit too much infix :( What about 50.btc 25.usd Keeps it inline with the time API as well with 20.seconds and what not.

Thanks for commenting! I'm still learning Kotlin and I overlooked the usage of get() with vals. This will be the next syntactic sugar into the mix. I think it makes sense.

When I was designing the API, I created methods like toUSD() and toEUR(). But with 306+ circulating/tender currencies and 2000+ cryptocurrencies, I thought it could lead to a bad experience when using code completion.

just curious - what is the backend api framework that N26 uses ? is it kotlin specific ? or generically spring boot or something ?

In Brazil (where I worked) we used Kotlin + Ktor. In Europe, they are heavy Kotlin users.

References:

Brazil: https://blog.eriksen.com.br/en/platform-engineering-n26 Europe: https://medium.com/insiden26/engineering-at-n26-a-tour-of-ou...

cool. whoever uses these libraries better validated it very well.

What's the best library for JS or TypeScript?

This is cool and it's great to see people adding better first-class support for currencies in as many languages as possible!

I am the author of a similar crate in the rust ecosystem: https://crates.io/crates/currencies

major features include:

* support for all ISO-4217 currencies (though not all have been explicitly tested as it is hard to find native users of some)

* compile-time macros for specifying an Amount in the native format (with symbol, etc)

* support for non-base-10 number systems (there are a few ISO currencies that needed this)

* every currency uses an appropriate backing data type, and new currencies and backing data types can be defined as long as they meet the trait requirements

* opt-in ability to enforce only checked math ops (but using the usual +,/,-,* etc symbols). This is critically important for crypto and finance applications where a panicking math op can, for example, brick a blockchain or real-time trading system

* support for parsing and printing currencies in their native format at runtime

* currencies use the appropriate format style (https://github.com/sam0x17/currencies/blob/main/core/src/cur..., i.e. symbol can be "suffix attached", "suffix spaced", "prefix attached", "prefix spaced")

* support for a number of cryptocurrencies, basically popular ones and ones I've bothered to add. Will always accept PRs adding others!

* ability to define your own currencies using the `define_currency!` macro. Though these will not be supported by the built-in `amt!` macro unless I add them to the crate.

e.g., here is how a few of the core currencies are defined:

define_currency!(USD, u64, 1_00, "$", "United States Dollar", PrefixAttached, true, false);

define_currency!(BTC, u64, 1_00000000, "BTC", "Bitcoin", SuffixSpaced, false, true);

define_currency!(ETH, U256, u64_to_u256(1_000000000000000000), "ETH", "Ethereum", SuffixSpaced, false, true);

One disadvantage right now is there is no ability to have a generic "amount of some arbitrary currency" other than through generics, as the underlying traits aren't object-safe. A good way to work around this is to define an enum that contains all the currencies you plan to support. I am working on a feature that will let you easily generate this enum at compile-time :)

parsing is done using my Quoth parsing crate which provides a very safe, lexer-less way to do parsing of UTF-8 strings that relies on recursive parsing in a way somewhat similar to syn, but there are no token streams https://crates.io/crates/quoth

Great reference, Sam. I will definitely bookmark your library and learn with your implementation.

For cryptocurrency data, take a look at the DTIF.org dataset: https://github.com/eriksencosta/money/blob/trunk/docs/append...

> no mainstream language has a first-class data type for representing money

I don't think that's correct, absent some no-true-scotsman gymnastics.

F# has units-of-measure (UoM) out of the box, and it supports decimal numbers. I've come across a python library for UoM as well.

The big problem with handling money in code is not, IMO, the rounding (your allocate function is a nice utility but it's not core); it's unit confusion - adding baht to ren mi bi, adding cents to euros, etc. This problem is very well solved by F#'s UoM.

Ok, what do I do in F# if I want to not think about the low level details of FX conversions, rounding, etc? Which libraries can I use?

I don't know either well, but I took a glance at both and it doesn't seem like UoM is well set up for making decisions based on which peer is going to give you a better exchange rate.

We sometimes pretend that money is measuring something, but in reality it's much messier than that.

> (...) making decisions based on which peer is going to give you a better exchange rate.

Neither does a money data type.

It looks like multiple exchange rates per currency pair is supported: https://github.com/eriksencosta/money/blob/4bef95a1d2158e308...

Sounds interesting! How would it look like? Do you have some code to share?

Here's something along those lines in F#:

https://gist.github.com/williamcotton/b67ff641eeec7673131715...

> I don't think that's correct, absent some no-true-scotsman gymnastics.

Yeah, I think OP's claim is not valid. Even .NET provides System.Decimal, which by design and explicitly mentions financial calculations.

Taken from the intro docs:

https://learn.microsoft.com/en-us/dotnet/fundamentals/runtim...

> The Decimal value type is appropriate for financial calculations that require large numbers of significant integral and fractional digits and no round-off errors.

This is often not what you want with monetary calculations. You want the rounding: you'll be making a payment of $25.86, not $25.85714285714... But you just want to make sure that the next payment is $25.85, not $25.86 or $25.857142851, and that all 7 payments together equal $181 and not $181.02.

I can't speak for C# but the Python Decimal type handle significant figures correctly.

> The decimal module incorporates a notion of significant places so that 1.30 + 1.20 is 2.50. The trailing zero is kept to indicate significance. This is the customary presentation for monetary applications. For multiplication, the “schoolbook” approach uses all the figures in the multiplicands. For instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600.

Languages indeed have support for currencies and decimal numbers. My implementation is based on Fowler's Money pattern. The Money object is thus a value object representing a monetary amount in a given currency.

https://martinfowler.com/eaaCatalog/money.html

> However, no mainstream language has a first-class data type for representing money...

I beg to differ. Java has "Decimal" class which guarantees to be safe from IEEE754 floating number side effects, and specially created to handle cases like money and financial calculations.

In these days it's used as BigDecimal, it seems [1].

[0]: https://docs.oracle.com/javase/8/docs/api/java/text/DecimalF... [1]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Can BigDecimal tell me which currency a monetary value is denominated in?

No, but Java has a specification (JSR 354) to build money and currency APIs [0].

A library built upon it can be found here [1].

[0]: https://jcp.org/en/jsr/detail?id=354

[1]: https://javamoney.github.io/

Tell me you've never worked in fintech without telling me you've never worked in fintech :)

Decimals aren't enough. You have frequent currency conversions and all sorts of other chores. Using a fixed-decimal datatype doesn't solve those problems by itself, it's just a tactic.

See JSR-354 then: https://jcp.org/en/jsr/detail?id=354

Yes, I never worked in fintech, but lots of my family members work or worked in banking sector. So, I'm not an alien when it comes to money, and how it works and processed in IT side of the things.

> However, no mainstream language has a first-class data type for representing money

This is literally the entire point of COBOL

"no mainstream language..." COBOL is has not been a mainstream language for many decades now.

It's still quite mainstream in domains where they manipulate a lot of money : banking/insurance.

The core systems of many old institutions still relies heavily on COBOL.

I think I will add a footnote on COBOL. COBOL is huge in Brazil, lot of insurance/financial companies are still using mainframes.

There are billions of lines of COBOL in production. It's not going away any time soon.

I think most of this is covered by a good Decimal API, currency stuff probably shouldn't be embedded into a language because it changes: currencies come and go, get redenominated etc. Although one simple thing that would be useful is keeping track of abstract units, e.g. throwing an error when attempting to do 10 USD + 10 EUR.

Don't we embed timezones, though?

Timezone conversions don't change by the minute. Currency conversions do.

Do most applications use the minute-to-minute conversions or some daily rate?

I'm fairly sure that for example for RON, the Romanian Central Bank only publishes daily rates, for example.

what type of language is kotlin?

Is it functional , OOP or something else, which paradigm does it represent?

It's all of the above.

Most modern languages (including everything from Java to OCaml) don't fit neatly in any one box because they have added a bunch of features from other paradigms that make multi-paradigm programming possible. Kotlin is that way to an extreme, because instead of strapping on functional features to an OOP core like Java did it was designed out of the gate to be all of the above.

When I program in Kotlin I'm constantly shifting between "paradigms" based on what is actually needed in the moment. It's one of the best languages I've ever worked with for learning the strengths and weaknesses of different programming styles because it has such strong support for most of them.

Kotlin was originally designed for running on the JVM, so it is generally object-oriented, but the language and the standard library allow for and encourage a functional coding style.

Kotlin is well-suited for DSLs, especially declarative ones (see kotlinx.html[0]).

[0] https://github.com/Kotlin/kotlinx.html

This understates how functional Kotlin is—you wouldn't say that Scala is generally OOP with some functional support just because it was built on the JVM. Scala's clearly a functional language with some OOP support.

Kotlin, in turn, is very balanced. The standard collection library uses OOP syntax (chains of method calls), but is extremely functional in its philosophy towards how we think about manipulating collections.

I think a comparison to Scala is apt. Working with both languages makes it quite clear to me that Scala is most certainly much more functional than Kotlin. Kotlin is really not very functional in practice, in that it really doesn't encourage a functional style, nor is it optimized for the patterns that are common in functional programming.

Scala has `Try` and `Either` for modeling domain failures as values as opposed to throwing (unchecked) exceptions, which are side-effecting. Scala also has for-comprehension syntax built in to make it more convenient to compose and chain fallible operations that use `Try`, `Either, `Option`, etc. Kotlin's `Result` type is not designed for modeling fallible operations (not a sealed class, no type parameter on the error variant, error must be `Throwable`, etc), and Kotlin does not offer convenient syntax like for-comprehensions despite being more than able to (given that many of us have implemented near-perfect analogues to Scala's `Try` and for-comprehension syntax in Kotlin). Similarly, no official Kotlin libraries or APIs ever return errors as values and always opt for throwing exceptions instead.

Scala's collection types are implemented as persistent collections, which are optimized for cheap updates. If you want to avoid direct mutation in Kotlin, you have to make a full copy of a collection.

Scala's mutable and immutable collection types are actually distinct from each other and cannot be used interchangeably. In Kotlin, List<T> is a supertype of MutableList<T>, which means I can pass a MutableList into a function that expects a List. That means that the list can be changed in another thread while my function is running, so I can't even assume that checking `list.size` at two different points in my function will return the same value.

Scala has actual type classes. Kotlin has extension functions which are not nearly as useful (and they have very surprising semantics when it comes to static vs dynamic dispatch). Type classes are certainly not required for functional programming with a statically typed language, but it definitely helps when it comes to modeling things without needing to lean on writing more classes and/or utilizing inheritance.

Also, Kotlin's "functional" APIs on collections are much more janky than Scala's. For example, if I have a `Set<T>` and I call `.map((T) -> R)` on it, Kotlin will give me a `List<R>` while Scala will give me a `Set<R>`, which makes way more sense.

Kotlin is cool, and it would be dishonest for me to say that it's not at all functional, but after having worked in other many other languages, I'm very comfortable saying that Kotlin is an OOP/imperative language first with some functional stuff added in (sealed classes, convenient lambda syntax, top-level functions, and some of the typical collection combinator APIs). Whereas Scala is quite clearly designed to be actually GOOD for functional programming without taking an extra-hard performance hit.

Exceptions are great. Whats not great is not having them expressed in the type system via checking. I think Kotlin's greatest mistake is not improving upon checked exception handling. Though it looks like they're going to be moving forward in the future with errors as values via union types [0]. Scala also has some experimental work around putting exceptions into the type system via capabilities [1]. I really like Scala's solution because it lets checked exceptions work across higher order functions and Scala has enough syntax sugar to make handling exceptions pain free.

[0] https://youtrack.jetbrains.com/issue/KT-68296 [1] https://docs.scala-lang.org/scala3/reference/experimental/ca...

I have LOTS of opinions about this topic, but I'll try not to ramble.

I always found checked exceptions (Java) to be mostly fine/good. I sincerely believe that a lot of the hate for them in the last decade is just cargo culting. I get a small dose of schadenfreude when I see someone doing mental contortions to simultaneously explain why Rust's Result type and handling (and similar features in other langs) is awesome, and Java's checked exceptions are terrible and definitely not 95% similar in DX and semantics...

The one point against checked exceptions for me is that if I'm trying to model a domain failure, it really doesn't make sense to collect a stack trace. For example, if I'm writing a logIn function that takes a username and password, then it's totally normal for the username and password to be invalid. Why would I want to spend the CPU time collecting a stack trace when someone simply typed in an incorrect password? Do we want to collect a stack trace when the password is correct and the user gets logged in?

So, in that sense, I do have a small preference toward expected failure modeling to be somehow different from "true" "exceptions".

I do also agree with you that Kotlin's biggest original sin was to throw away checked exceptions without replacing the concept with ANYTHING. Of course, as you've pointed out, they're backtracking on that somewhat by trying to add this concept of errors as a kind of ad-hoc union type. (aside: they also backtracked on their choice to not have type classes because "extension functions are good enough" by trying to do context receivers, which is ending up being really hard and probably more complex than just doing damned type classes in the first place...)

I do kind of like the direction that Swift is moving with finally adding specifically typed throw signatures (essentially Swift now has checked exceptions, but they're aren't actually traditional exceptions because they don't collect stack traces and unwind the stack- they're just syntax sugar around a Result/Try type).

But, my prediction is that the pendulum is starting to swing back in favor of checked exceptions. In the next decade we'll continue seeing languages adopt mechanisms that are essentially checked exceptions. But, they will be slightly different and definitely called something else so that we don't have to admit that we were wrong to shit on the idea for 15 years.

EDIT: Also, I do follow Kotlin developments closely, but I haven't actually worked in Scala for several years, so I had no idea about this capabilities idea. Thanks for the link.

I have a ton of opinions on exceptions too, mostly because I love them.

FWIW you can override the stack trace collecting behaviour of Java exceptions. Not collecting the stack trace makes exceptions really fast and thats actually how Scala is implementing their boundary/break feature. I do kind of wish that Java could backtrack and that the stack trace would only be filled in on RuntimeExceptions that are true panics.

I really feel like Java just needs investment on the language syntax to make checked exceptions good. Things like `try!` or `try?` from Swift would be nice and taking Scala's try { as an expression with case catch blocks would make it really fluent. I think most devs can agree that they want to know what errors can happen, but currently in Java its just a pain to deal with them. Brian Goetz originally had some ideas around evolving the switch construct for this [0] so at least we know making exceptions better is on his radar.

[0] https://openjdk.org/jeps/8323658

> FWIW you can override the stack trace collecting behaviour of Java exceptions.

Could I ask you to point to an example?

    class MyException extends Exception {
        @Override
        public Throwable fillInStackTrace() {
            return this;
        }
    }

Persistent collections for Kotlin are actually implemented in a first-party library: https://github.com/Kotlin/kotlinx.collections.immutable

I use it in almost every project because it works so well with StateFlow: https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...

That's not what I would call a "first-party" library. Yes, it's written by JetBrains and under the Kotlin project umbrella, but we have to add it to our project like any other dependency.

I can install a persistent collections library in any language. I know for a fact there are persistent collections libraries for Rust, JavaScript, Java, etc.

But since none of those are built-in, they aren't used by the standard library APIs, and they won't be used throughout the wider ecosystem.

And, I'm still not willing to call Java a "functional language" because I can install a third-party library for persistent/immutable collections and hopefully avoid the built-in collections as much as possible.

The JVM doesn't necessarily imply object-orientation. Clojure (a JVM language) is not really object-oriented at all; I'm not an expert but I think the only time objects are used in idiomatic Clojure is when doing interop with Java libraries.

Huh, I've never actually looked too hard at Kotlin. That is a lot more syntactically flexible than I thought it was! That HTML builder reminds me of Ruby DSLs a lot.

It's not really syntactically flexible, but made explicit syntax for the use cases other languages used flexibility for, like DSL-builders and extension methods.

This avoid the problem that you have in more flexible languages where everyone does a pattern in a slightly different way.

It's much more "multi-paradigm" or "unopinionated" than Java, but since it is a pretty thin layer over Java and uses its standard library, the ecosystem and idioms are still very much OOP by convention. But, I see the language itself as more akin to C++ in that it really doesn't strongly push much in one direction or another, but they also both lack built-in tools or optimizations for doing real functional programming. So, I'd say that Kotlin, like C++, is an unopinionated language that does well for OOP and/or imperative styles.

Like Java, but nicer. Used for Android app devel. Me, I would not call it multi-paradigm, because it really feels primarily like Java (though with many niceties), i.e., it is single dispatch ('this'), objects and classes everywhere. It is completely compatible with Java, and you can mix the languages freely (this is done in Android). It does have standalone functions.

Kotlin is a multi-paradigm language with OOP and FP support.

As a Java replacement, it's still mainly an OOP paradigm with some functional bits added. The type system is mostly unchanged from Java. Kotlin's null safety is interesting, but JVM null pointers are nowhere near the problem they are in C. Otherwise its value proposition mostly relies on overcoming perceived constraints from Java syntax, allowing to redefine parts of the language to build DSLs. Whether this is a good idea is disputable; ask any maintainer of large projects where those capabilities were used in full, or just look at the continuing train wreck that is Gradle.

A mess, in my limited experience, so far

[flagged]

I dont understand the need for this.

I always has used integer data type and counted cents. Why need this?

You don't need if your solution fits your use case. The library is an implementation of Fowler's Money pattern: https://martinfowler.com/eaaCatalog/money.html

More precision and/or more safety. Will depend on the domain/audience/... the software is being written for.

crypto needs support for decimals, determinism, rounding directions, uplifting to higher dimensions during long term accrual, down lifting fosome kind of quantization, path dependance.

eth is whole number 10*18. usdc is 10*6.

usd is if to speak is 10*2 number.

solana eth price is less than eth eth price because of bridge risk.

etc.

there are on decimal money to out of crypto.

there are logarithmic money in crypto.

so many many moneys.