this post was submitted on 26 Jul 2025
139 points (97.9% liked)
Software Gore
1181 readers
1 users here now
A community for posting software malfunctions
Deliberately bad software or bad design is not software gore, it must be something unintentional
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient and shear it
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Honestly none of those "gotchas" sound at all surprising to me. A currency enum and
f64
for the amount will cover 99.99999% of use cases. u64.u64 fixed point if you really need it (you probably don't).Try dates/times. That's serious pain.
Wow uh, nope. A f64 is a double, floating point precision type, aka not precise. You should never store currency values in that, otherwise you, well you just recreated the exact bug we see in the image above.
Bud, like I said, the problem comes off as "lol it's so easy", but unless you have literally worked with money before - real actual dollars and cents, it is much more complex than you give it credit for.
Your approach may appear fine, it may look fine, but with money precision matters. Floating points are not precise, they are an exponential representation of a function that will give you a pretty good estimation of the value you want - but they are not precise. In money, you must be precise. You fuck up that value, you get customers calling in, you get banks rejecting your transfers, you get governments closing you down because your code is shit and they don't trust you to manage people's money.
Now, I'm not a jerk, I'll tell you the correct answer, we should all learn. The correct format to store money in? A string. Immutable, perfectly precise to whatever precision you want, and whatever the customer types in is exactly what you can store. You parse that string to make sure it's valid, you use your currency enum as you said (which I wouldn't btw, currencies actually change more often than you would expect), to make sure it passes to a correct numerical value that fits within the bounds of that currency. If you need to mutate that value, in the same language you go to a precise type, mutate, and then return it back as a string value. Storing in a database then you store the value as string, and best practice is to store the "imprecise" amount next to it as whatever the database supports. That way, you have the auditable real value ($4.00) stored for use on reports and taxes, and the imprecise ($3.99999999898998888181) that you can use for sorting, filtering, and regular database options.
Strings also should be used over the wire, aka in json payloads in rest apis. This is because JavaScript and other languages parse the number types as floats, which again are imprecise. String is the only safe way to translate money between languages and data stores.
For Rust, as I assume that's what you're referring to, you should use something like rust_decimal - crates.io: Rust Package Registry https://crates.io/crates/rust_decimal a precision based crate for handling money.
f64
is perfectly precise.Lol ok.
If only we had this thing called rounding...
Have you seen office space?