> thank you Rust decimals represented as JSON floats

What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec.

> If I ever see a monetary value stored in something else than integers I'm going to run away screaming

That’s good, then we’ll likely not be working on the same system :) I consider running from “amounts as integer” systems these days (but usually unfortunately can’t). In an idealized codebase that only seasoned financial programmers are allowed to touch, it can go well, but such a system is usually either overly exclusive or risks becoming brittle.

> JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec.

I think that's the problem they were trying to describe. Without a formal spec, systems won't agree on how to handle floats. JS engines treat numbers as 53 bit signed floats, so passing a well defined decimal there through JSON means losing precision at the edges.

Money stored in integers gets around the issue by simple virtue of not really needing more than 53 bits to accurately represent the values anyone is going to encounter.

There are downsides like all the extra math or functions to handle doing the math everywhere money is manipulated or displayed, but this is the sort of thing where static typing is really helpful, and isn't too hard for juniors to understand that they should always use money functions to work with money data.

With I need to represent monetary amounts through JSON, I encode it as a base 10 string and wrap it in quotes so that the JavaScript engines treat it as a string. Conversion back to int happens after the string has been parsed and validated.

I do this with HTTP GET and POST form requests as well. In HTTP, everything is a string (even if that string is JSON).

I'm sure there is something I don't know here, but how is working with integers "brittle"? The only issue I see is rounding down by default, not sure if that is even an issue or not. At any rate, it seems a lot less brittle than floats or bigdecimal style number classes.

The brittleness comes from the fact that the number of implied decimal digits per currency isn't always well-defined across all stakeholders and systems.

If you're only working in a single currency, there's usually no issue.

As a general rule, you always include the currency code (EUR, SEK, USD etc.) and if possible also the amount of decimals, when using minor units.

Currency codes can be found in ISO 4217.

Yes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database.

Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.

ISO 4217 also defines the number of significant digits after the decimal separator if Wikipedia is to be believed.

> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t).

In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?

Native decimal types, if your system has them. Many languages and databases used in financial contexts do.

But native decimal libraries are almost always floating point.

Do people not know what a floating point number is?

That’s alright, the important part here is that they’re decimal, not binary. You don’t want 0.1 + 0.2 to equal 0.300…004.

There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.

An integer for the value (scaled by number of decimals) and an integer value for the number of decimals. Different systems may use different values, even for the same currency or asset.

What exactly do you think a floating point number is?