Yeah, the reasons have been spelled out well in this thread. I honestly asked because if there is something I have come to expect from this language, it’s that the decisions always seem to have really solid reasoning, even where it doesn’t jive with my personal tastes. I figured from the start there were legit philosophical and technical reasons for it and looking through the mailing lists made that clear enough.

Yeah. Honestly, I kinda wish I hadn’t even brought that up. It was just me talking about how I like the way Ruby can be written, especially for a non-programmer. I don’t think Elixir would be better for it, but I also think it’s still fine to appreciate what other languages can do. It turned into… a fixation I didn’t intend in the conversation.

I think anyone who has been programming for very long knows how important precision is with dates. We all have horror stories, lol. The system I am working on right now is a real beast if you’re not extremely careful about bloody time zones!

This was the main thing I came for because that was the bug I hit. No warning. No nothing. And I know why it’s that way.

And hey, since I have you here… I love Elixir! It’s what I use professionally. I was a long time Rubyist (about 12 years) and I made the move. I still miss some bits but there’s no going back. You and your team have done such a good job with both the language and community. I can’t tell you how much it’s improved my work and me as a programmer.

I am continuously humbled by your ability to address even hostile comments with incredible wisdom and humility. I appreciate you taking the time to comment. Seriously.

We don’t have the concept of primitives, as in those languages, but integer and float are built-in types and decimal is a custom one. So there is a clear demarcation here. In any case, if I could, I would support decimal + integer, but we can’t do it today without making it slower for all cases and without breaking guard semantics. The shortest way around this is to have decimal as a native VM type.

Other than that, I am very glad to not have date + 1.days, because there isn’t anything arithmetic about it. For example, it is not guaranteed that (date + duration) - duration == date. I do like 1.days though, as a mechanism to express durations, but I would be 90% as a happy if we had Date.shift(date, months: 1, days: 10) in Elixir (PRs are welcome, I consider this to be the last calendar feature missing in Elixir).

Finally, the hope is that once we have the type system, we will warn if you give a struct to any >, >=, <, and <=. It is pretty much a language pitfall that I hope we can address more reliably.

You could do something like this:

defmodule MyDecimal do
  defmacro __using__(_) do
    quote do
      import Kernel, except: [+: 2, -: 2, ...]

      def left + right do
        Decimal.add(left, right)
      end

      def left - right do
        Decimal.sub(left, right)
      end

      # ...
    end
  end
end

For me, the lack of operator overloading is part of what makes Elixir a good dynamic language as it still cares about types. It’s also part of (all of?) what is enabling the possibility of strong arrows (if we get some static typing). If you looked at a language like OCaml it goes even further. + only adds ints, you need to use +. to add floats! And you must explicitly cast one side if you want to add a float to and int.

I don’t know if this is the exact reason Elixir doesn’t overload, though.

CompareChain might help with some of your use cases (shameless plug: I’m the author). I had similar headaches working with DateTime structs. It’s easier to read code like:

• left <= right vs
• DateTime.compare(left, right) != :gt.

CompareChain is a sort of middle ground where you can write this:

import CompareChain

a = Decimal.new(1, 42, 0)
b = Decimal.new(1, 42, -1)
compare?(a >= b, Decimal)

It’s not perfect, but I find that it helps.

Used to think so myself (had 6.5y with Rails before I moved to Elixir) but honestly, my day is not ruined for having to write this instead:

NaiveDateTime.add(date, 2, :day)

Also don’t forget that time is very finicky, we still have leap seconds and summer/winter time jumps. There are situations, just in the right two dates of the year, where adding a few hours to a datetime will lead to ambiguous times, e.g. check this out: Timex.AmbiguousDateTime — timex v3.7.11

Having arithmetic operators for something that can jump back or forth beneath your feet I would find suboptimal and unpredictable. I’d prefer patter-matching on the result of a datetime operation, including the ambiguous results.