Actually, you have it backwards. Enterprises care a great deal about long term maintenance and have large codebases. However, they are also very conservative and prefer the tried and tested approach.
Startups don't typically care about maintenance because, for the most part, they are going for a binary win/lose outcome where in a win they have so many resources that 5x higher maintenance costs are ok, and in the lose they close up shop/pivot and throw the code out. And startups are usually more open to taking a chance on new/different tech.
If there were 3-4 large enterprise companies with 200kloc+ Haskell projects in use I feel Haskell could see long term 20-30% uptake in the enterprise. But few enterprises will take the risk of being one of the first.
Let's have an honest conversation. Haskell is a great programming language. It might be the best. It is not going to get more than a 20% market share in the programming community. It could get 1 percent, which is about 5 times what it has now (measured in available jobs) and 25 times what it had 5 years ago. It could get 5 percent. It might even get 15 percent.
Much of our industry is based on trend-chasing. This 25-year-old language that happens to be really good, but whose strongest proponents even admit that it will never have a dominant (25+ percent) market share like Java or Javascript or PHP, is not a shoo-in for "next dominant paradigm".
Functional programming may be the next important paradigm and we're seeing the best programmers and the most important work gravitate toward it, but it's never going to be the go-to tool for the business-driven Scrum engineering that seems to dominate the mainstream of software.
Having said that, the tricky part is sticking to pure FP and coordinating data structures. Not impossible, but it's a foreign area for many shops.
Disclaimer: My development these days is almost exclusively in Haskell
In 2015, Haskell is almost as fast as OCaml, albeit less predictable and therefore possibly still less desirable in certain financial settings. Haskell has a better concurrency story, though.
That sounds like all the functional stuff Scala has, right? What's it missing? Also, since when does 'functional' mean 'algebraic types'? Aren't those completely different things? Are common LISP and Scheme 'not as functional as scala'?
it's multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional ( source: https://en.wikipedia.org/wiki/JavaScript )
Many languages known as functional (Scala, F#, Lisp, Scheme, OCaml) are multi-paradigm languages (check out Wikipedia!), purely functional programming language like Haskell are the exception (https://en.wikipedia.org/wiki/Purely_functional ). And the IO part is hardly functional.
@Down voter: care to explain?
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.
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.
That's not to make a dig at Scala. It's way better than Java. It's also really complicated, and the need for JVM compatibility is a big part of that. Then you have the compile speed issues, the problematic tool chain, and the fact that average Java programmers, given Scala, will create unmaintainable nightmares.
I'd use Scala over Haskell when I wanted JVM interoperability, or if I needed to train people up quickly. For a "bet the whole farm" play, existing programmer familiarity actually matters a bit less-- "the whole farm" is rarely bet on a one-month project-- and I'd pick Haskell first.
Did you ever use Haskell? Those issues are far worse in Haskell than in Scala.
You just hear more people complaining about Scala, because it is used, while Haskell projects are usually not developed and maintained anymore after the author finishes his PhD.
On the other hand, Erlang is pretty ubiquitous behind-the-scenes, and I wouldn't be surprised if some enterprises do develop their internal software in it.
On the third hand, since Elixir uses Erlang's runtime, it'll be subject to less required battletesting for the same reasons that JVM-based languages (like Clojure, Groovy, Scala, and JRuby) are quickly gaining popularity in enterprise environments that already use Java.
They are. Though of the 4 examples you gave, only Scala's really being used to build systems, though Clojure's being used by some who don't mind forgoing static typing. Groovy's a scripting language used for short test and build files, and for Grails. I don't think JRuby ever got used much in production.
Scala is probably the larger of the two options - big users notably include Twitter, Linkedin, Morgan Stanley, JP Morgan, Walmart and Reuters.
The use cases for F# tend to be smaller scale and more UI-oriented - internal reporting tools at a hedge fund, for example. That's not to say they are simple CRUD apps, merely that F# apps are not usually massive distributed systems.
That's not really true, there's quite a lot of F# use for "big data"/"data science" stuff going on, and one of the other big sells is use for financial analysis (hell, even one of the official tutorials centers around processing raw stock price data).
I would also say that it does appear Clojure is getting some strong uptake in web dev on the JVM, thanks largely to the quality of some of the APIs and libraries for both Clojure and Clojurescript. It's quite possible and even easy to develop your entire web stack in Clojure (I'm currently doing just that at work right now). Heck, if you want to shell out for it, you can even use Datomic and have a database that's built in it ...
NB: Our Climate Corporation teams are running Clojure.
"What is functional?" is a difficult question my partner and I ponder often. As someone else here said, simply having functions as first class values seems insufficient as that would include Perl, JavaScript, C (fxn pointers) and other langs as "functional." Saying supporting any mutability at all removes your status as "functional" means Lisps aren't functional, which seems to ignore the history of FP. Erlang doesn't have monadic IO but is highly regarded by many as functional. If our definition essentially includes only Haskell as "functional" then the term seems useless. So we define as functional any lang that supports functions as first class values AND significant enforced immutability.
Scala's first class functions, default immutable data structures and "val"s compile-time enforcing immutability without too much ceremony put Scala in the FP category for us, along with the Lisps, MLs, F# and Erlang.
The flow of dominant programming languages has been something like:
Perl -> Java,Ruby(Rails+Gems+APIs) -> Java,Scala,Javascript,Ruby
Not that those are the only ones floating around at our company, but Scala definitely has a leg up.
Erlang's a bit of a special case; while you probably won't see many enterprises consciously using it (unless they use Jabber/XMPP via ejabberd, of course), it's rather abundant behind-the-scenes with communication infrastructure, and multiple large telecom providers and OEMs (including - obviously - Ericsson) use it for their equipment and infrastructure.
Scala, Clojure, F#, JavaScript aren't functional languages. Functional programming is programming with pure functions. It is not "first-class" functions. It is not closures. It is not static typing.
