I know they're not common in modern HLLs since we have magic do-everything array ADTs, but I find it kind of hilarious to describe (singly-)linked lists as "esoteric."
Personally, I enjoy having (really cheap) lists around, and wish more HLLs had them as one of their fundamental, low-level abstractions. There's something extremely satisfying about accumulating elements backward by consing, and then reversing at the end. I'm always worried in Ruby/Python that push()ing elements onto an Array might do all sorts of stupid re-allocations at just the wrong time; lists, on the other hand, have extremely obvious time-space complexities for all their operations.
That's something that can be said about all the Erlang ADTs, now that I think about it—each one has been carefully considered such that you can guess the time/space complexity for each operation and be correct. Erlang (and Elixir) also has a policy that if two ADTs both have an operation with the same semantics, but the two operations have different complexities, then the two operations will get different names—which is amazing for making bad ideas (like trying to do random-access on a list) obvious.
(And really, while we're on the subject, it's tuples that are the weird Erlang type. As handy as they are as an underlying implementation for records et al, there isn't really much theoretical basis for having a set of N fixed-size non-enumerable product types, each with integer-indexed, untyped slots.)
I know they're not common in modern HLLs since we have magic do-everything array ADTs, but I find it kind of hilarious to describe (singly-)linked lists as "esoteric."
Personally, I enjoy having (really cheap) lists around, and wish more HLLs had them as one of their fundamental, low-level abstractions. There's something extremely satisfying about accumulating elements backward by consing, and then reversing at the end. I'm always worried in Ruby/Python that push()ing elements onto an Array might do all sorts of stupid re-allocations at just the wrong time; lists, on the other hand, have extremely obvious time-space complexities for all their operations.
That's something that can be said about all the Erlang ADTs, now that I think about it—each one has been carefully considered such that you can guess the time/space complexity for each operation and be correct. Erlang (and Elixir) also has a policy that if two ADTs both have an operation with the same semantics, but the two operations have different complexities, then the two operations will get different names—which is amazing for making bad ideas (like trying to do random-access on a list) obvious.
(And really, while we're on the subject, it's tuples that are the weird Erlang type. As handy as they are as an underlying implementation for records et al, there isn't really much theoretical basis for having a set of N fixed-size non-enumerable product types, each with integer-indexed, untyped slots.)