Nil > 25 returns true – is this expected behavior?

Yes, comparison operators can be used across types. As for why nil > 25 returns true, see the good ol’ docs. Of note: nil is simply syntactic sugar for the atom :nil (you can prove it with iex> nil == :nil).

I see. I’ve been programming in Elixir for about 10 years, and I had never run into this “behavior” before—perhaps because I always used is_nil/1 or is_number/1 in guards. But today, my tests started failing after I added a guard like when ver > 25.

What surprised me is that two AIs insisted it couldn’t be true. ChatGPT even gave me several links “proving” it would raise an error, but those links pointed to Elixir pages that didn’t actually mention anything related to this specific case.

thanks

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.

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.

Well sure, there are years worth of “information” on the internet from folks claiming “Elixir is just Ruby with some extra dos”.

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

I no longer trust LLMs with quantitative questions that have objectively true answers. They’re just not so good at that, nor will ever be perfect. They will though, be as good or better than a human, which is a good goal.

What I’m seeing now is AI programmed to come up with a “correct” answer in tightly confined answer spaces, giving confidence scores along the way.

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

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

…and a clunky implementation of method_missing!