Show HN: Kotlin Money (blog.eriksen.com.br)

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

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.

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!

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

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

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

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

    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.

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

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.

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

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

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

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

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

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

> 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.

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