Erlang - Actor-based software design and its inherit benefits are trivial to implement compared to (most) other languages. By design, almost trivial distribution across many nodes without resorting to specialized APIs (that aren't common across all platforms) or separate coordination languages.
Ada - The type system and the manner in which it can be used to constrain your software (in a positive way) makes ensuring certain safety/reliability much easier. Compare in C, an int is an int. If I make a "temperature_t" it's just a double or something that's aliased. Where as "kelvin_t" in Ada can be made to be only the positive real numbers.
Lisps - I'll include Common Lisp, Emacs Lisp, Scheme, Racket, clojure, etc. The meta programming (ruby has this too, actually) makes it much easier to develop large programs almost automatically. The meta programming nature allows you to, within the same language as the primary program you're aiming for, extend your language and program. This reduces the friction of the meta programming tasks, consider C. You can use meta programming, but it requires at least one other language.
Plenty of others, three (languages and families) off the top of my head.
Erlang's language is concise, well-designed, and oriented around the concurrency model. Try tacking it onto C and it won't work well [0]. Take that concurrency model and put it into Python or Lisp or Smalltalk, and it could work fine. Those are expressive languages that are sufficiently malleable to bring in foreign concepts in a native looking fashion.
[0] It won't look as clean. It'll work, but it won't be clean. We actually use a very similar model in a project at work. But there's so much bookkeeping because it's C that Erlang hides from you. Other expressive languages would be able to absorb that bookkeeping and hide it from you as well, but C isn't expressive. It's precise. It does what you tell it to do. But it's not able to hide things cleanly behind abstractions that the language itself isn't already built to handle.
I agree with Lisp (and it has even been done by key Erlang people), I am willing to believe SmallTalk (though it would be tempting to put the process boundary around every instance), but Python? Have you watched the early talks about why Erlang is designed the way that it is? Python is way way too imperitive in nature, having a syntax that makes functional subsets extremely limited and awkward.
In my limited experience I feel my intuition is correct that you could make something that looks and mostly acts like erlang's concurrency stuffs in python. But it's not my main language by a long shot so I could well be wrong.
Idris and Coq which have more advanced type systems allowing you to create proofs for you software. There are not many languages that allow this.
And Shen which has a Turing complete type system meaning it is very flexible but type checking may never halt in certain conditions. I do not know of another language with these properties.
Haxe allows you to target absolutely anything and if you miss some exotic it is trivial to allow generation for it. It is also quite mature language with a macro system. Again, maybe MonkeyX compares somewhat but has far less backends and making a backend is not so straightforward.
K and Q and their parent APL which allow you to write the most terse code you will ever see (some make a sport of it).
Forth you can implement in a few hours on any platform and yet is a very powerful language which makes it easy, once you get used to it, to write terse but easy to understand code. This one I would say is, compared to other languages including Lisp, easier to implement naively while still keeping solid perf. There are also lists of minimal instruction Forths which show you how powerful and easy the basic constructs are and how rapidly you can make a toy language.
Most languages have these type of functions, once you've read the file into an array its just array/list manipulation. I haven't compile checked this but here's the same as a C# one liner:
with open("foo.txt.") as f:
foo = sorted(list(set(line.strip() for line in f])))
with is a context manager that will automatically close the file once it's out of scope, not required but it's much cleaner and safer. Should the code change you don't have to worry about the call to close the file getting lost. The call to set() could be replaced with a set comprehension, {i for i in sequence}, but for clarity I used set().
It's certainly not the most efficient way to do it but it's simple and clear.
Haskell and Scala are pretty awesome at embedded DSLs, because of do-blocks. You can use them to bind some value to a symbol (i.e. assign a variable) inside the eDSL, which isn't possible in most languages. (Contrast this to, say, eDSLs in Java, which are limited to fancy builder patterns).
In Python you can code an MMO, manipulate a database, set off a Hadoop job processing petabyes of big data in parallel on a thousand servers, conduct statistical analysis on the result set, generate beautiful and meaningful data visualizations, run a web server to make your program accessible to the world, stick an API onto it, and give artificial intelligence to a robot. As Heinlein wrote, "Specialization is for insects."
It's probably more prevalent than OCaml at this point despite it's young age. It builds on top of Erlang/OTP which is quite battle tested and used by several major companies. The community behind it is quite strong as well.
Ada - The type system and the manner in which it can be used to constrain your software (in a positive way) makes ensuring certain safety/reliability much easier. Compare in C, an int is an int. If I make a "temperature_t" it's just a double or something that's aliased. Where as "kelvin_t" in Ada can be made to be only the positive real numbers.
Lisps - I'll include Common Lisp, Emacs Lisp, Scheme, Racket, clojure, etc. The meta programming (ruby has this too, actually) makes it much easier to develop large programs almost automatically. The meta programming nature allows you to, within the same language as the primary program you're aiming for, extend your language and program. This reduces the friction of the meta programming tasks, consider C. You can use meta programming, but it requires at least one other language.
Plenty of others, three (languages and families) off the top of my head.