Honestly? I think this is just one of those things you need to be paranoid about.
Comparing structs falls into an unfortunate local minima of Elixir’s design. There is a total ordering on its terms, so a < b is always valid. So the compiler is a bit limited in what it can do. Though as @garrison noted, you do get warnings in certain circumstances.
However, unless the compiler knows for some reason that the result of & &1.inserted_at will always be a %NaiveDateTime{}, there’s nothing for it to do. You could maybe do:
Enum.min_by(entries, fn %{inserted_at: %NaiveDateTime{} = ndt} -> ndt end)
But at that point, you’re bending over backwards to get the compiler to tell you something you clearly already know. Though maybe if you use TypedEctoSchema, the compiler would be able to infer.
One other thought: always consider adding an order_by clause to your queries. Similar to this particular gotcha, it’s very easy to unknowingly rely on the order a query even though you didn’t specify it. E.g. we had a series of heisenbugs in our tests where I was blithely asserting on the result of Repo.all(). The results rows usually ordered the same, but not always.
