A big part of the issue is that they are niche languages so “supply and demand” naturally leads to increased salaries for a smaller pool of developers.

In which case, why would companies even choose these “expensive” languages? In general, because they make certain things easier for smaller teams of developers and because developers are often happier using these languages than more mainstream ones.

Functional languages generally have immutable data at their core and are often built around a more consistent, higher-level of abstraction than mainstream languages.

These two aspects help you avoid a large class of bugs (those caused by mutability) and provide more “leverage”, allowing you to write more expressive code and therefore less code, which in turn means less bugs proportionally.

Where I work, we adopted Clojure back in 2011, and gradually rewrote all of our backend systems into Clojure as we needed to touch any existing code or add any new functionality. We’re able to manage a pretty large code base (large for Clojure — 140k lines) with just two developers at this point, and we’re able to turn features around very quickly. Our problem space happens to be very data-driven (online dating with a multi-tenant system that powers ~40 dating sites and apps) which suits Clojure very well, as it excels at data manipulation/transformation.

Matt's answer was pretty biased, but it's much better now :). However, it's obvious he prefers Scala. Consider the perspective of someone who loves to write F# and has done some Scala, but didn't enjoy it very much at all:

Technology stack - The latest editions of mono are quite fast. Very close to the MS CLR in fact. This is mostly due to a new garbage collector. Also, Oracle has shown it is willing to sue others who make small modifications to the stack. And let's not forget about that yahoo toolbar in every Windows install of the JVM. Microsoft on the other hand has been nothing but helpful to the Mono team and doesn't push crapware with their Mac Silverlight install.

Libraries - The libraries available for .NET tend to be much better designed than those for the JVM. This is partially due to .NET's much better implementation of generics and partially due to the fact that Microsoft has tools like fxcop. Also, .NET allows you to interface directly with COM, DLLs and C++ and so allows for very fast native implementations to be built and abstracted into nice managed interfaces.

Tools - F# has three well supported IDEs: Visual Studio 2010, Emacs (fsharp-mode) and MonoDevelop. In fact, some members of the F# team primarily use emacs. I've had the unfortunate experiences of using IntelliJ IDEA, Eclipse, and NetBeans in the past and hope very much that I'll never need to again. None of them even approaches what Visual Studio has to offer.

Type Inference - F# has fantastic type inference which greatly simplifies coding once you understand how it works. Scala has type inference on a similar level to C#: That is, only very simple. While new users to F# do get compilation errors due to type inference, this is actually a good thing. This is the compiler telling you that your code is incorrect. It's a safety feature. As they often say in ML, once you get the types right the program writes itself.

As functional languages - Scala is about as functional as Python. That is, it supports many of the constructs but isn't built around them. For example, Scala does not support true tail call optimization. I do agree that Scala is more object oriented and F# is more functional. However, I find my code ends up much more concise and readable when objects are used only occasionally. Perhaps this makes Scala more accessible, but it also locks users in to the old and broken object oriented model.

Tail Call Optimization - As a functional language, one of the biggest problems with Scala on the JVM is the lack of true tail call optimization. As Jon Harrop often points out, this means no fast or deep co-recursion, no untying the recursive knot and no continuation passing style. These are all important things in functional programming which you can't do in Scala on the JVM.

As object-oriented languages - Scala has a lot of object oriented features. Too many in fact. I've been neck deep in several Scala projects that heavily overused its multiple inheritance features and so were quite difficult to understand. F# has all of the standard features that C# has, plus some interesting things like anonymous objects based on interfaces with object expressions. It's just enough to play nicely with object oriented code but keep it out of your clean functional abstractions.

Syntax - Both F# and Scala allow you to define arbitrary operators from any combination of a special set of characters. Actually, none of the operators that come with F# are magic, they are all implemented as very simple library functions. You can see this if you just type (|>);; into the interpreter. You'll get: ('a -> ('a -> 'b) -> 'b). Internally this is implemented as: let inline (|>) x f = f x. They might seem complex at first, but there are just a handful of them. Once you get them down, it's completely unambiguous and way less typing.

Scala isn’t a “functional language”. It’s a generic language that can do functional stuff better than the previous generation.

My hunch is that Scala is going to lose ground to Swift and Kotlin in this space.

Haskell is the language to learn if you care about a) the more advanced theory of FP, and b) the most powerful features of type-systems. It’s also a pretty great language for a bunch real applications these days. It won’t hurt you at all to learn Haskell.

Lisp is a great language with a tonne of good ideas. Since forever. And you can’t go wrong learning a Lisp.

But I personally, and yes, this is my bias, would recommend Clojure which is both

• a) a Lisp (so has 90% of what’s good about any Lisp), and
• b) a proper hardcore functional programming language (ie. with immutability, default laziness for collections etc.) version of Lisp (unlike earlier Lisps which are mixed paradigm).

The other advantages of Clojure are that

• c) like Scala it’s designed to be compatible with the rest of the Java ecosystem, so you can immediately start doing real useful work with it in any context where you’d otherwise use Java
• d) Also, in the browser, ClojureScript with Reagent (a React wrapper) makes writing browser-based UIs very civilized indeed,
• e) is just a beautifully designed language in general. Clojure is as simple and “self evident” as a language like Python. Things generally just work as you’d expect (given the paradigm and the obvious quirks of Lisp syntax). But it’s also more powerful and elegant than Python (code to do the same thing is both shorter and clearer)

So I love Clojure. It’s not perfect. There are times it’s not appropriate. But still I rank it as the best language I’ve ever met. And I would recommend it to anyone who wants to both develop their programming knowledge, and have a useful tool to do real work in.

My background: I've dabbled with Haskell on and off since it appeared almost 25 years ago. I've dabbled with F# a little (I took a workshop on it a couple of years ago and I've attended a few meetups, unsessions, and conference talks about it). I built a small production system in Scala a few years back. I've been doing production Clojure for four years.

As other responses have indicated, if you really want to learn FP for its own sake and in its purest form, Haskell should be your first choice. It is absolutely the gold standard of FP languages at this point and what you learn there can easily be applied to any other languages you subsequently choose to learn. It will make you a better programmer. Period.

If you want to ease into FP alongside your current language of choice, then F# is a very good option. F# has a great pedigree -- coming from OCaml -- and you would be able to write parts of your system in F# and integrate that into your C# application very easily. If I worked primarily on a Windows platform, I would be a diehard F# fan, based on my exposure to it so far.

As noted by Reese Currie, Scala is a complex language, with a complex type system (that Odersky et al are working to simplify in the future) and it is also a hybrid OOP/FP language which means you can easily write non-FP code and miss some of the real benefits (and good concepts) of FP. I don't recommend it as a "first FP language" and only partially recommend it as a "better Java". Don't get me wrong: it's a very impressive and capable language but I think you need a solid FP background before you can use it effectively.

Finally, there's Clojure which is unique amongst the languages you list in two ways: it is the only dynamically typed language, and it is the only Lisp. I like it best for those two reasons but it's not for everyone. In the same way that Haskell will make you a better programmer, a Lisp will also make you a better programmer (in different ways, perhaps), because it is a very different idiom from "traditional" programming languages. Everything is data, and in Clojure it is all about the abstractions (sequences, protocols, etc). Clojure combines the best of OOP (several forms of a la carte polymorphism) with the best of FP (immutable data structures, a focus on small pure functions), as well as offering a pragmatic way to deal with mutable state (Software Transactional Memory) for practical, real-world FP. Clojure runs on the JVM, so the whole Java ecosystem is available to you (some view this as a negative point!), and it also targets JavaScript (via ClojureScript), and the CLR (via ClojureCLR) although the latter doesn't have as mature tooling and support as the other two platforms.

I’m with Gerry Taylor in saying that Golang doesn’t belong on this list. Go is the opposite of exotic — as a language, it’s basic. (Its compiler speed is noteworthy, but that’s somewhat outside the scope of the language itself.)

Why are languages, like Scala, Haskell, Erlang, and Golang, considered exotic languages?

The reason that [some programmers] regard Scala, Haskell, and Erlang as exotic is that each of them breaks the only conceptual model of interacting with a computer that these programmers know: the do-this-then-do-that-then-do-the-other-thing model known as imperative programming.

The languages people learn in school or college CS classes, or that they pick up teaching themselves, or that they learn in bootcamp, are with high probability imperative languages. They may or may not also support object-orientation (C does not; Java does; Go does not; …), but the basic structure of a block of code in all is do-this-then-do-that-then-if-we’re-in-this-condition-do-the-other-thing-else-do-the-other-other-thing.

The three languages in the question either do not support an imperative style, or else it is strongly unidiomatic.

Haskell

Haskell, for starters, is entirely declarative — there are some language constructs like the do-notation syntactic sugar over monadic binds that can feel a bit imperative (since monads are the idiomatic pattern to sequence effectful operations), but experienced Haskellers learn to read them as declarative as well (since an unreferenced value produced by a monadic bind, like everything else in Haskell, will never be instantiated due to laziness).

Take an example like mergesort. This algorithm is pretty easy to express in imperative terms:

Take the sequence you want to sort. Cut it in halves. Recursively sort each half. Then allocate a target sequence of the correct length and pop elements off the front of the sorted halves and push onto the target sequence until both sorted halves are empty.

There are, as usual, a lot of implementation details to get wrong when translating this sequence of human-language instructions into computer language, but that’s not my purpose here. Instead, I want to illustrate how Haskell would express this algorithm entirely declaratively:

merge :: (Ord t) => [t] -> [t] -> [t] 
merge [] ts = ts 
merge ts [] = ts 
merge (a : as) (b : bs) 
 | a <= b = a : (merge as (b : bs)) 
 | otherwise = b : (merge (a : as) bs) 
 
mergesort :: (Ord t) => [t] -> [t] 
mergesort [] = [] 
mergesort (t : []) = t : [] 
mergesort ts = 
 let (lefts, rights) = splitAt (div (length ts) 2) ts 
 in merge (mergesort lefts) (mergesort rights) 

I don’t even write Haskell and I could produce this in a few minutes (most of which was looking up partially remembered syntax). But if you’re coming from C or Java or Python, it’s likely that even trying to read this makes your head hurt — that’s a perfectly normal reaction. It’s not just unfamiliar syntax hiding familiar operations, it’s a necessarily unfamiliar syntax expressing an unfamiliar way of even thinking about programs.

(Note also: this is not a production-ready mergesort, since merge is not tail-recursive and will self-call length ts times. This can be avoided, but it would make the example even harder to read.)

Erlang

Erlang does something similar, but very different. It upends the familiar way of structuring a program’s control flow, but not by turning everything into an expression — instead, Erlang leans hard into the Single Responsibility Principle in the sense that if an object needs something done that’s someone else’s responsibility, you send a message to that other object telling them what they need to do and relinquish control flow. Where in traditional imperative programming one would block until the other object finished its part, in Erlang you have to architect the system in such a way that once Object B finishes its part, it knows who to send the job on to next to continue processing.

In a sense, this moves threads of execution onto the heap — the underlying runtime is in charge of scheduling all the objects onto system threads, but there is no one-to-one relationship between conceptual threads of execution and system resources.

What this means for the programmer working in Erlang is, there’s no more do-this-then-call-service-a-to-do-that-then-do-the-other-thing-then-call-service-b-to-do-the-other-other-thing. There is only

• execute my single responsibility; then
• pass the thread along to the next guy and relinquish control.

Scala

Programming in Scala can be a strange hybrid beast, because it enables all three of the herein described patterns/paradigms. (Full disclosure: I write Scala for my day job, and I love it.) You absolutely can write straight-up imperative code in Scala — but if you’re on a professional software team, your teammates will not find this amenable and will point you to the team code standards document.

Scala is designed to support declarative syntax, and the mergesort example above translates readily into Scala (using parentheses and dotted member access instead of whitespace):

def mergeSort[T: Ordering](ts: List[T]): List[T] = { 
  def merge(lefts: List[T], rights: List[T]): List[T] = (as, bs) match { 
    case (Nil, _) => rights 
    case (_, Nil) => lefts 
    case (a :: as, b :: bs) if a <= b => 
      a :: merge(as, rights) 
    case (a :: as, b :: bs) => 
      b :: merge(lefts, bs) 
  } 
 
  ts match { 
    case Nil | (_ :: Nil) => ts 
    case _ => 
      val (lefts, rights) = ts.splitAt(ts.len/2) 
      merge(mergeSort(lefts), mergeSort(rights)) 
  } 
} 

But Scala also supports an Erlang-style actor-based message passing architecture, enabled via the Akka framework. The language is sufficiently flexible that the Akka library writers could build in Erlang’s “send an object a message” primitive via a domain-specific language; they have since continued to expand the library to support type-safe messaging (where Erlang, inspired by Smalltalk, supports messaging arbitrary values to any receiver).

I’ve heard complaints that Scala is a “kitchen-sink” language, because it enables all these patterns. I haven’t found this to be true in practice. Most small applications don’t benefit from an actor model in the first place; those that do still need the internal logic of each actor — the code that fulfills that actor’s single responsibility — to be written in readable idiomatic Scala. Truly imperative code (that is, functions or blocks that do more than bind some local variables and then do one thing with them) is frowned upon (because it’s harder to debug and maintain). The key is to have a team of people who agree on a style and a standard (and who can identify the problems that the choices in the style guide are meant to prevent) and are committed to a readable, maintainable project.

The best way to sum up the advantages is “you get more done with less work.” For example, given (approximately) the number of lines of Elixir code to do the same amount of work in Go or Java, you will write 4x as much Go or Java code. But you also spend less time debugging because immutable values, lack of inheritance, collection-oriented functions and (depending on the language) type-checking all eliminate bug-creation.

Shout out to Erlang/Elixir pattern-matching. It is weird at first, coming from OOP, but soon becomes indispensable. And eliminates a bunch of logic. Which means (surprise) fewer bugs.

So if you want to accomplish more with less code and fewer bugs, go functional. I took to the BEAM VM over the Java VM, so I went Elixir.

In terms of language features?

CL is like dynamically typed C++ — it’s old and encompasses everything. Imperative features, higher-order functions, (unhygienic) macros, signals system (like exceptions but more advanced) and the most advanced and complex object system (with multiple inheritance and multimethods plus Meta-Object Protocol). That’s why it, much like C++, is rather cumbersome to use in practice.

That’s also why more recent Lisp dialects like Clojure cherry-pick just a subset of its features that are more coherent and easier to use. Plus Clojure has first-class principled support for concurrency which was not an issue at the time of CL inception.

And Haskell is nothing like that, nothing like that at all. Just don’t even try to compare Haskell to Lisps or other dynamically typed functional languages. It’s two completely different kinds of “functional programming”. Almost all of Haskell features are about types (ADT, GADT, higher-kinded types, rank-n types, existential types, type families and so on). And most of its abstractions are Algebra-based and type-driven. You have almost nothing like that in dynamic languages.

The most important way in which Haskell is different from other widely know functional languages is that it uses lazy evaluation (values are only computed when they are required by another computation) rather than the more common “eager” or “strict” evaluation strategy where expressions are evaluated immediately.

A side effect of lazy evaluation is that there’s no obvious way to perform effects like printing to the terminal, communicating over a socket or even changing a value in an array. What is the value of the expression print("hello, world.")? When is this value required? In most languages, this is a nonsense question. The print function returns void or in some languages it returns a nil value intended to be discarded (in some languages it returns the number of bytes printed, but this value, too, is often discarded).

In the context of laziness, if the value is never needed, the expression doesn’t execute. Without going into too much detail, Haskell’s solution is that effects produce a value, and the effect doesn’t actually happen until you unwrap the value by chaining effects together in a sequence of callbacks which invoke some runtime magic to perform the effect (this is what the fuss over monads is about).

This may sound like a limitation in the language and that is true—the positive side is that this limitation encourages separating your computational core from the parts of the code that do effects—something you should be doing in every language anyway.

Most popular functional languages use eager evaluation and effects just happen in order wherever they appear in the code without any special unwrapping required

Another way in which Haskell is different from some functional languages is that it has a types system from the ML tradition, like SML, OCaml, F#, Scala and some others. Rust also has such a type system, though it is not functional.

In this system, types are conceived of as sets of values, where new types can be defined in terms of products or unions of other sets of values. Because the compiler knows every value which belongs to every type, pattern matching (a kind of fancy switch case) can be used to ensure every possible case has been matched.

In practical terms, this means you’ll have an explicit code path for every possible program or function input. This can drastically decrease the number of possible fatal errors at runtime, even eliminating them entirely in most cases (aside from cases like running out of memory)

Just to throw in my 2-bits, I wanted to reacquaint myself with functional programming several years back and looked at Scala and F#, among other languages.I went with F# because object-oriented development is secondary and have used it regularly for the last 2+ years. I disagree with Matt that extensive object-oriented support is beneficial. Here's my thinking...

For "gently" diving in to functional programming, pick whatever language works with your regular environment -- Scala on JVM, F# or C# on .NET, or even Python and, if you really want, C++. But I think this is a mistake.

IMHO the real benefit to learning a "functional language" is learning to "think" functionally -- data is immutable, functions are first-class elements and applied TO data opposed to being bound together with data, and so on. Reading Chris Okasaki's book Purely Functional Data Structures was the eye-opener for me. For making this mental switch, object-oriented support is useful for utilizing existing libraries, but can end up being a crutch. If one is using features like multiple inheritance, again IMHO, the mental switch hasn't been made.

All that said, I think the choice of language is much less important than learning a new way to think and look at a problem. It's a good skill to have and opens up alternative solutions to many problems.

As languages facilitating functional programming, they are actually quite similar. They're both strictly evaluated "object-oriented" languages, with two very important differences:

F# has better type inference. Scala's type system is more complex, hence inference is more difficult to implement. In Scala, inference generally flows pretty well from arguments to results, but not so well from results to arguments. F# also has better metaprogramming facilities (so far).

Scala has higher-kinded types. Also known as type-constructor polymorphism, or higher-order generics. This is an absolutely indispensable feature in my opinion. Whereas in Scala you can write libraries that use type constructors (such as monads) parametrically, the only way to do this in F# is with code duplication or code generation.

However, OCaml (another ML variant like F#) has recently added type constructor polymorphism, so we may see this in F# at some point.

Common Lisp isn't limited to being purely functional, although it does permit it. CL is mature, has amazing debugging and development features, is quite efficient, and has been ported to many environments natively, as well as running on the JVM (and work in progress for JavaScript).

Haskell is mature, has fair debugging features, is quite efficient, purely functional, and runs natively on a few environments.

Clojure is immature, and in my opinion has serious flaws in its implemetation which require a deep understanding of both Clojure quirks and those of the underlying environment (Java, or JavaScript), is nightmarish to debug, and runs only on the most popular virtual machines.

NB “nightmarish to debug” by comparison to eg, Common Lisp or native JavaScript, not perhaps as compared to, say, Assembly language.

Francis King has provided a nice answer. I’m not sure I’d call Kotlin a functional language—though perhaps it is “more functional” than Java, but it lacks functional data structures in the standard library. It is a nice language for the JVM in any event. He otherwise mentions Clojure, Erlang and Elixir—all fine languages.

I add some additions:

• OCaml is a direct predecessor of both Scala and F#, and a cousin of Haskell. It still holds its own as a statically typed functional language, especially for programmers on a Unix-like platform. It’s known for balancing theoretical soundness and an advanced type system with pragmatic features for real-world applications. It also supports classical OO—and is actually one of the best implementations I’ve seen with thoroughgoing structural typing, though it isn’t used much in practice.
• Standard ML is more or less the sister language to OCaml. It perhaps has a greater emphasis on purity than OCaml or F#, though not to the same extent as Haskell. It lacks any OO features, which many people see as a good, but it also lacks many of the other goodies of OCaml (GADTs, polymorphic variants, first-class modules, etc.)
• Racket is a dialect of Lisp. It could almost be consider a non-standard Scheme implementation with many extensions and quality-of-life features—and indeed, it uses the Chez Scheme compiler as a backend. Racket’s primary usecase is as a platform for prototyping new programming language.
• Common Lisp is a standardized definition of the Lisp language. It has MANY features and, though dynamically typed, leading implementations like Allegro and SBCL can produce incredibly well-performing code.

I think, aside from those mentioned in the question and those mentioned by Francis in his answer, these are the major ones. However, there are many other functional languages which might be useful for various niches.

PureScript, Elm, and ReScript are statically typed functional languages which compile to JavaScript for use in the web browser or with Node.js. PureScript is a purely functional language which is very similar to Haskell. Elm is also inspired by Haskell, but a bit farther away. Elm comes with its own frontend framework for purely functional DOM interaction. ReScript is a language inspired by (and originally forked from) OCaml which has great bindings for working with React.

Agda, Gallina, Idris and ATS are dependently typed languages in which formal proofs of correctness can be constructed for functions. Agda and Gallina are more specifically for theorem proving applications (Gallina is specifically for specifying proofs in the Coq theorem prover). Idris and ATS have more general programming goals in mind. Idris looks similar to Haskell and is the more user friendly of the two. ATS looks more like ML and is too complicated for me to grok, but has performance comparable to C++.

Futhark is a statically typed, purely functional language for writing parallel code that runs on CUDA, OpenCL or multi-threaded processors. It’s great for advanced vector mathematics, and it compiles to object code which can be called from other languages.

There are many other functional languages. Clean is another one that comes to mind. It’s lazy and pure like Haskell, but has an entirely different system for dealing with effects.

Haskell, as a general rule, is best to test your knowledge of FP concepts. The language has advanced features that enforce things are done in an FP style ie pure functions.

Haskell, in production, is best for web-servers and backend development, as well as academic research.

Scala runs on the JVM and so has interop with Java libraries and language. The language supports both OOP and FP paradigms. The styles can be easily mixed, and therefore it is hard to define a specific paradigm. Scala does not enforce an FP style ie pure functions.

Scala is best at backend development but can run almost anywhere the JVM is. One distinct difference of Scala over Haskell is the that has access to all of the Java’s libraries, so if there is not Scala library, a Java one can be used instead.

F# runs on .NET and is a functional first language. The language paradigm encourages an FP style but supports an OOP style. F# is a great language for learning FP, as the laziest/shortest implementation in F# is generally a functional one. F# does not enforce FP style specifically pure functions.

F# has full interop with C#, so if a library is not available in F#, a C# one can be used.

F# has seen a lot of success on the backend, though the language can also do front-end development with the fable compiler and react. The language has tools for data-science, and can even call into the R programming language through a feature called the type-providers. F#, through the use of Xamarin, can be used to build a native app iOS, Android, UWP (Windows 10) and Linux. F# also supports windows desktop development using WPF.

Also .NET now runs on any platform including Mac and Linux. Visual Studio is now available on Mac too.

I prefer Haskell for learning FP, F# for production use. F# is functional to avoid bugs but pragmatic enough to ship quality code on any platform.

Simple answer, they are not "pure" functional languages. Assuming your question implying why we have languages that use functional elements which are not so niche (i.e. mainstream), its because of a number of reasons..

1. As stated before, they aren't "pure" functional languages. Scala mixes imperative and OO (which deals with modules, packaging, namespaces etc etc) with functional elements. Clojure is likewise similar (although clojure has its own definition of OO (i.e. multilevel dispatch), it has added a lot of stuff to the standard LISP)
2. They made compromises to leverage existing ecosystems. Both run on JVM, and both have very good interopt with Java libraries.
3. Sought of in tangent with #1 and #2, both designers of the language (and hence the languages themselves) have a more pragmatic rather than theoretical approach. Both languages clearly admit the merits of functional programming, however admit at the same time that FP isn't the solution to everything (for a wide variety of reasons)
4. Both languages use the FP paradigm to solve problems that are currently very relevant, and play to FP's biggest strength, i.e. distributed programming with explicit management of minimal (or even stateless) systems. This is mainly in the backend, web server space. As a counter example, you will notice that languages like Haskell have attempted to "solve" IO in many different ways (on the basic level with Monads, and then using concepts like arrows and FRP) which haven't really caught on, even though they have been researched for a long time.

Not sure what you’d consider a traditional programming language, but all those languages that you mention here are functional (or also functional). This makes them more flexible and expressive ― as a case in point, imagine that you can pass functions as arguments to functions ― how flexible this can make your code and designs, and how better it may mirror your thoughts, if you’ve not been brain-washed too much into totalitarian object oriented paradigms.

The more mathematically inclined you are, this would be more enticing to you. This stands in stark contrast to languages like Java, which are not functional, yet have been very aggressively popularized for several decades. Even in Java 8 and 9 you cannot properly practice functional programming, and you are still encouraged to model everything through object metaphors, and if it doesn’t fit ― force it harder, which is many times misaligned with the nature of the problem at hand.

Another advantage is that most these languages encourage immutable values and data, which make your CPU work a bit harder but reduces the chances of you writing code that blows up under concurrency.

Some of the languages you mention have additional advantages ― mainly in areas like concurrency and scalability ― where they offer safe building blocks for concurrency (mainly Erlang, Elixir and Clojure, but much less so truthfully scala).

Of course these languages also have downsides, i.e. you might be too young or old to adapt, and of course they tend to have a lesser footprint in the commercial developer community (except maybe Erlang in Telco). Some of them sport less ready-made and well supported libraries to choose from. With scala you also have backward compatibility issues between versions of the languages and such additional earth-like considerations you’d want to explore before making very strategic choices. Also you need to know when to use mutable data and a bit of OO design even when using these languages, depending on the nature of what it is that you need to accomplish.

Don’t believe what a lot of the other answers are saying: functional programming languages are hard. People say “they are not hard, it just requires a different way of thinking”, well getting your head around a different way of thinking is hard almost by definition. Some of the concepts involved in FP can be really difficult to get your head round but then once you do, it suddenly becomes beautifully elegant and simple and you forget the pain you went through.

With that in mind, Scala is a nice half way house from Java to hardcore functional programming. You can view it as a not quite full blown FPL or a better Java.

However, the main reason for its popularity, in my opinion is that it is a drop in replacement for Java. You an even run Java and Scala in the same JVM and they can talk to each other natively. This means you can leverage all of the massive Java ecosystem with Scala.

There’s also the Play framework which is to Scala as Rails is to Ruby or Django is to Python and although it works best with Scala, Play integrates nicely with Java too for the reasons given above.

The problem with a question like this, is that the answer is going to be so subjective its utility will be based almost entirely on the perceived authority of the person answering, no?

My experience of "why people choose Scala" has almost always been that they were already using Java and the transition was seen as a natural evolution, and into a language that for better or worse is seen as "Enterprise" by people making decisions without actually being at the coalface of software development. That's not to say that Scala is bad, or even not as good as Clojure or Erlang, just that it has the greater momentum in the wider sphere of the IT world. Scala does appear, for what it may be worth, to be vey well suited to the kind of message queue handling and event-based system creation that is characterised by large, high-availability, connected systems, and this would be bourn out by looking at how Twitter used Scala to scale their "streams".

I can't comment with any authority on Erlang, except to say that its origins do seem to speak volumes as to where it might be most useful - telecommunications, and so to boil it down to brass tacks, message passing, transmission, receipt etc. The fail early, fail often, without stopping (?) approach to technical design that Erlang empowers is a powerful proposition - if you have lots and lots of throughput and you need to "stay up" regardless of what may happen, then by all accounts you could do worse than choose Erlang.

Clojure is, if I may borrow the words of a wiser man, the programming environment / toolset most able to mitigate risk in software development endeavours. The features of the language when coupled with REPL-driven development and the ease of testing a functional language that also imposes immutable state, can lead to a great deal of productivity with greatly reduced risk or uncertainty, if done well at any rate.

The answer to the question, really, is there is more at stake than the language that you choose. How available are people with the knowledge and skills that you will need to adopt the tools that you want to use? How compatible with your use-case(s) are the existing toolchain for the language that you want to use? Has anyone solved a similar problem before with the language that you are thinking of using?

Scala, Erlang and Clojure are all versatile, powerful tools, well suited to many aspects of the wider domain of software engineering, so in the end rather than picking the one that is "best for X", pick the one that is best for you, in every way possible, and it is likely that you will have a good outcome.

Scala's type system is pretty complex, which can be a hindrance to those who don't take the time to understand it or a help to those who do. It is more multiparadigm than strictly functional, meaning, you can mix imperative, object-oriented, and functional code. This enables you to ease into functional programming, but may also prove to be a hindrance as you may frequently be tempted to just go imperative if you can't figure out a functional approach. There are good books available like Functional Programming in Scala by Paul Chiusano and Rúnar Bjarnason. Scala plays well with Java, making it a helpful thing to fit into my toolkit.

I can't comment with any expertise on the others you've listed but I'll give you some lightweight subjective impressions.

I like Lisps and gave Clojure a try but for some reason I just can't get into it; it seems hard to find information on how to do things, and I was daunted by having to learn yet another build system (leinengen) just to make anything. Other alternatives are Common Lisp, Scheme, and Racket. Learning one of the Lisps is extremely worthwhile for the perspective it gives you on programming. I find it makes you better in any language.

I played with F# a little but I'm a Linux guy and not so interested in Microsoft stuff. I did like what I saw, though. It's a derivative of OCaml, which on Linux is a remarkably fast language compared to other FP languages I've tried, rivalling and sometimes beating C.

Haskell is very purist; the temptation to code in a non-functional way would not be available to you, and it also has a few really good tutorials. I may come back to it someday if I have time. Nothing quite gets the love of FP fans that Haskell does; I'd almost say it is like a cult following without intending any disrespect to Haskell lovers. From what I can see their devotion to Haskell is well deserved.

For marketability I suspect Scala and F# are near the top of the FP heap IMO. Marketability has never been a good measure of the best tools, though.

Thanks for the A2A, hope it helps.

This is a limited choice. Here is my personal ranking:

• Haskell: It is a great language but if you are into theoretical stuff (Mathematics, logic, algebra, etc.). It is the only remaining strictly pure functional language. It is very good for parallelism also.
• Ocaml: It is not a strictly functional language (you can do loops and so on). It now has reasonable tooling (dune, opam, tuareg, etc.) but is still not wonderful. It is mostly on Unix.
• F#: It is the Windows version of Ocaml by Microsoft and is fully integrated with the Windows environment and APIs.
• Erlang/Elixir: It is why I answer here. Erlang is very good but as far as I know, Elixir is strictly better than Erlang and is fully compatible with Erlang (It works on the same Erlang Virtual Machine). Erlang/Elixir is very good for servers handling a lot of traffic (For example Whatsapp is in Erlang). It has the Phoenix web environment.
• Scala: a JVM language. Very powerful but relatively complex language. Can be used in all areas where Java is used.
• Clojure: a JVM language that is Lisp-like. Same use case as Java but you have also ClojureScript a cross compiler to Javascript.

So, it all depends on your use case.

Take all the answers you got from everyone else and add these 3 reasons why YOU (and not necessarily everyone else) should immediately dive deeply into F#:

1. XAMARIN - Learn F#, and you can use your "functional-first" programming skills to do native app development for Android, iOS, OSX and Windows.
2. ASP.NET CORE 1.0 - Core 1.0 is a complete rewrite of asp.net, and it lets you use F# to write web apps, and those web apps run 600 percent faster than Node.
3. WebSharper - Compile F# to JavaScript and build great web apps.

Because it is the only language that runs in web browsers, JavaScript has been a necessarily evil. However, it wasn't until Node.JS that it's full stack potential was realized, making JavaScript THE hot langauge of the day.

But F#... it can now do full stack web, and native apps. That is a LOT more benefit than learning any other FP anyone could name.

I adore Elm, a pure FP that compiles to HTML, CSS and JavaScript, but I also adore getting stuff done in the smartest way practical, and .NET CORE and Xamarin have just vaulted F# to the top of the REALLY smart langauge to learn list.