While there is no runtime warning for the reasons explained above, it’s worth noting that the new type system might be able to catch it and warn at compile time when it is sure types are disjoint:

comparison between distinct types found:

    nil > 25

given types:

    nil > integer()

While Elixir can compare across all types, you are comparing across types which are always disjoint, and the result is either always true or always false

You sound like one of those people who actually know how to use a dynamic programming language properly Also, we’re in the BEAM world here so I believe you meant “behaviour”

As grumpy old man jumping on the opportunity to rant this has been fairly common recently, “common” meaning this is the ~7th time in a couple of months I’ve seen a question online where people said they just asked AI, and not just for Elixir questions! I’m sure it’ll all be “fixed” soon enough, but I still enjoy reading docs.

Back on track, another little gotcha is that true and false are also sugar for :true and :false, so when you throw nil into the mix and compare them it’s done so alphabetically. I know a couple of people who got tripped up by this because they assumed that since true is greater than false that false would be greater than nil, but it’s not. Though again, if you aren’t abusing dynamic languages then you’ll never run into this

k, I’m off to go yell at a cloud.

software developers in particular are prone to being convinced by these hazards and few in the field seem to have ever had that “oh my, I can’t always trust my own judgement and reasoning” moment

The LLMs appear to have transposed behavior over from Ruby, FWIW:

irb(main):001:0> nil > 25
Traceback (most recent call last):
        4: from /usr/bin/irb:23:in `<main>'
        3: from /usr/bin/irb:23:in `load'
        2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        1: from (irb):1
NoMethodError (undefined method `>' for nil:NilClass)

As you’ve noticed, the BEAM instead defines a total order (TLDR “everything compares to everything”).

This is mostly useful for code that handles opaque terms, like ETS’s ordered_set. The rest of the time you usually want to know (either by guards or by correct code) that you’re comparing terms of the expected type.

There’s a great writeup in The BEAM Book, including the rules for all the other kinds of terms.

Hmm, have you tried nil > 26? It might be that nil equals to something between 26 and 25. We should try binary search