[actsasbuffoon]

I like Scala, but it's still got mutable state, for loops, and lots of other imperative trappings. It's got some functional features, but I don't consider it to be a functional language (IMHO). If Scala is functional, then so are Ruby, JavaScript, and a host of other languages with higher order functions and the ability to be immutable, so long as you make the effort to not mutate anything (though anything is immutable by that logic). That doesn't make Scala bad. I actually enjoy writing it most days, but I think it's not quite accurate to call it a functional programming language.

For that matter, even Clojure has enough imperative parts that I don't consider it to be functional. Maybe I'm just overly strict in my definitions.

Anyway, Elixir qualifies, but isn't heavily used. I hope that changes some day, because it's a beautiful language. It manages to be principled about being functional, while also having an easy learning curve, and rock solid dependability. I want to see Elixir grow, because a language this good deserves to be popular.

According to the Red Monk rankings, Haskell is close to Scala in usage. The learning curve is much higher, but I love writing it. I love the clean, simple code that Haskell pushes me towards, and it usually does the right thing the first time I run it. It seems to be gaining traction lately, and Stack has me excited about the possibility of things ramping up even further.

[runT1ME]

I'm not sure how familiar you are with scala if you are equating them in equal 'functional power' to Ruby and Javascript. Have you read Functional Programming in Scala? The fact that the language supports immutable records out of the box, type classes, monadic comprehension all make it much more pleasant to deal with the realities of immutable data.

You can write immutable java, but the language doesn't make it easy to at all. Look at the hilariously bad builder pattern (which is as good as it gets in Java) compared to the right way of doing things in Scala.

[willtim]

Sadly I'm sceptical that the JVM can support practical and efficient use of functional structures such as monads. I hope this will change.

[jbooth]

What's Scala's superior alternative to builder patterns? You can have lots of final members in a constructor in Java, too..

[runT1ME]

State monad and/or lenses when appropriate, which is made quite pleasant to use with for comprehension's syntactic sugar.

[jbooth]

You mind pasting an example? I typically find higher kinded types, monads etc to be more of a pain than the problems they're solving (builders & constructors not really that painful IMO), but am really trying to keep an open mind.

[yummyfajitas]

Sure, here's an example with lenses, taken from actual code I've written:

    (for {
      _ <- EventLenses.duid := UserDuid("12345")
      _ <- EventLenses.contexts := Seq(EventContext.NilContext)
      _ <- EventLenses.url := "http://news.ycombinator.com"
    } yield ()).run(originalEvent)

This code will take an event, set it's duid, contexts and url. If you squint hard enough it almost looks like:

    originalEvent.duid = ...
    originalEvent.contexts = ...
    originalEvent.url = ...

The thing that's cool about lenses is that they compose nicely. E.g., the contexts lens is defined as:

    val contexts: Lens[Event, Seq[EventContext]] = query >=> getterMLens("cx") >=> Lens.lensu(...)

This means that first we take the query lens, compose it with a lens that gets the "cx" parameter, then do the actual work of decoding the "cx" param.

[jbooth]

Hey, thanks for filling in. So basically a facade over the original object only masking some fields.. yeah, not really my cup of tea personally, I'm fine with approx the same amount of code for a boring builder and/or constructor call to duplicate an object, or, if appropriate, a mutable object. But it's definitely nifty.

[runT1ME]

another great thing is it's 'replayable'. If the event is stored in an atomic reference, you can get optimistic transactional semantics by running the state monad, comparing the results to the previous by using a CAS, etc. So you have free concurrent transactional semantics from using the state monad.

[Aqueous]

While I agree that the ability to fall back on stateful imperative code makes it not a pure functional language, once you get into an immutable pattern it becomes less and less convenient or desirable to fall back on mutable data structures. I can't remember the last time I was even tempted to make something mutable. Also, in my experience it's required very little effort to convince new hires that are new to Scala to adopt this pattern.