Here is the code one more time, but now as more idiomatic Elixir with named functions in a module (rather than anonymous functions in IEx).

defmodule StrictExample do
  def factor(val) do
    for x <- 1..val, rem(val, x) == 0 do
      x
    end
  end

  def prime(val) do
    factor(val) == [1, val]
  end

  def is_large_number_prime() do
    prime(1000000000)
  end
end

It indeed has to do with the order of evaluation.
Haskell, being powered by a STG (Spineless Tagless graph-reduction machine), will move execution from the ‘goal’ back to where it originates.

In this example, it will indeed try to match [1, n] with the outcome of factors n. Indeed because of laziness is Haskell able to stop once two elements have been read from the output list of factor.

However, on the BEAM, we do not have this context-switching between looking at multiple parts of the output. Instead, for an operation like == we first evaluate both operands, and then check whether they are equal.

The optimization you expect here is (in eager languages) both rather limited in usefulness for practical applications, as well as rather high-level in the sense that as a human it seems obvious but for a compiler it would require many steps of intermediate reasoning.

To make an explicitly lazy implementation in Elixir, you can do this:

defmodule LazyExample do
  def factor(val) do
    # A lazy enumeration of all prime factors of `val`
    Stream.filter(1..val, &rem(val, &1) == 0)
  end

  def prime(val) do
    # We force the stream here, but only look at the first two elements.
    Enum.take(factor(val), 2) == [1, val]
  end

  def is_large_number_prime() do
    prime(1000000000)
  end
end

In this implementation, prime(1000000000) will indeed execute very fast.