[Jtsummers]

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.

[Jtsummers]

Re inconclusive:

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.

[saurik]

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.

[Jtsummers]

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.