That Range type is great until you have cases where you want variations on a Range, such as a MeasuredRange (same start and end, but with a new field called step_cost). Original functions which take a Range can't cope with this new completely different struct called MeasuredRange. So now we have to change them all to accept Range or MeasuredRange, or we need some kind of type heirarchy to relate them in appropriate ways.

The alternative is to accept the runtime risk of receiving a thing which doesn't have the start and end that you needed. Or of course if it were a very important piece of logic where failure was not an option, you just make your do_rangy_thing() require explicit start and end parameters. Then it's up to the caller to call do_rangy_thing(my_range[:start], my_range[:end]). Ultimately that just moves your failure risk up one level, though.

Likewise, you can use hash destructuring in Clojure like (do_rangy_thing [{:keys [start end]}] ... or pattern matching in Elixir like def do_rangy_thing(%{start: s, end: e}) ..., both of which will blow up at runtime if the hash passed in doesn't have the required keys.

Many people accept the runtime risk because it greatly simplifies code at the cost of runtime safety. The worst thing, in my view, is when languages try to bolt on some kind of type strictness later and end up solving the Range vs MeasuredRange problem by listing all possible accepted types or just throwing up their hands and saying Any.

I don't know Haskell, but from what I've heard about it I find it surprising that (int, int) is as common as you say. I thought they were very much about detailed specific types, with the theory "if it compiles, it works". My guess is that generic tuples are just an indication that some of the participants didn't want to deal with the complex type system and have a thousand different narrow case types defined.