Well, since you mentioned Haskell:

1. Pattern Matching. I find pattern matching to be much easier to read and write. Consider the definition of map and think about how it would be implemented in a language without pattern matching.

   map :: (a -> b) -> [a] -> [b]
   map f [] = []
   map f (x:xs) = f x : map f xs
   

2. The type system. It can be a pain sometimes but it is extremely helpful. You have to program with it to really understand it and how many bugs it catches. Also, referential transparency is wonderful. It only becomes apparent after programming in Haskell for a while how many bugs are caused by managing state in an imperative language.

3. Functional programming in general. Using maps and folds instead of iteration. Recursion. It's about thinking at a higher level.

4. Lazy evaluation. Again it's about thinking at a higher level and letting the system handle evaluation.

5. Cabal, packages, and modules. Having Cabal download packages for me is much more convenient than finding source code, writing a makefile, etc. Being able to import only certain names is much better than essentially having all the source files dumped together then compiled.

Acceptance Factors

I'd say a combination of various things, but I don't think they are all required. Some languages considered mature nowadays clearly do not satisfy some of these.

I'd say a combination of:

• Tooling:
  • mainline: At least one stable "official" or widely-accepted (de-facto or vendor-recommended/supported) tool suite (compiler, interpreter, vm, editor).
  • alternative: Some stable and not-so-stable alternatives of the above tooling (closed or open source variants, free or commercial variants, extensions, etc...).
• Community: An active , but not necessarily large group of followers and contributors.
• Recognition:
  • Some degree of recognition and use by some industrial actors (even if in a niche).
  • Some degree of recognition in popular culture (even if in a niche).

On Fame, Recognition and Maturity

Note that the differentiator here is on having strong and active criteria validators, not large or numerous ones. To clarify, consider these vastly different examples:

• Ruby was for a long-time a language with a large community-backing, an official reference implementation and so forth but could hardly be considered mature until it ironed out some of its rough edges. It was famous before being mature.

• On the other hand of the spectrum, some once very-widely used languages (COBOL, FORTRAN...) are now less visible but are still mature in every possible sense. They were once famous and mature.

• Also, some niche-languages are in my view definitely mature, inspite of their small (but established) market penetration. Consider Oberon or Limbo. They are mature but never got famous. Others, like R, are relatively famous in that their "niches" aren't really niches (bugs me when people call things like Scala or Clojure "niche languages", which they definitely aren't), though their field of applications are not exactly what you'd call mainstream.

On Stability

What's stable anyways? It's quite relative...

• Compliance?
  • To the standard (if there's one)?
  • To a reference implementation (if there's one)?
• Number of bugs? (hardly a good measure)
• Use in critical environments?

In general, stability simply means I don't get surprised on a daily basis when going about my average job using the language's toolkit, and I can get definitive answers on what should or should not happen when I attempt to do something with the language and its toolkit, whether it's at the build-time or runtime of my programs.

But stability for someone writing smartphone apps and stability for someone writing medical or avionics systems is a different kind of bird.