Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Which functional programming language is the popular enterprise choice?
46 points by _mc on July 3, 2015 | hide | past | favorite | 85 comments
If you use functional languages to build full or part of your application or you are aware of any such commercial applications please share!


Clojure is pretty big in some places. The list here: http://clojure.org/Companies includes Staples Sparx, Walmart Labs, Groupon, and several other well known names.


Jane Street is using OCAML. That or F# is my preferred choice.

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.


And many more companies https://ocaml.org/learn/companies.html


Do you know why Jane Street chose OCaml over Haskell? They have similar performance, right?


I'd guess because OCaml is a bit more traditional. It's strict and has no purity enforcements; it's a whole lot easier to transition people to.

Disclaimer: My development these days is almost exclusively in Haskell


Correct question would be - why Yaron Minsky chose OCaml. AFAIK Jane Street uses OCaml because they hired Minsky.


Jane Street started using OCaml in the mid-2000s, when Haskell wasn't (or, at least, wasn't perceived as being) up to snuff in terms of performance. Haskell has come a long way in the past 10 years.

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.


There were some early papers by Simon Peyton-Jones on financial contract modeling in Haskell too eg http://research.microsoft.com/en-us/um/people/simonpj/Papers... but OCaml had a much better performance story.


I'd guess Scala is the most popular choice, but for nearly every language you'll find a company using it for at least parts of their products.


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.


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.


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


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


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


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.


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.


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.


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.


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.


Can confirm. Scala is picking up slowly in financial services (JVM heritage certainly helps)


Clojure is gaining popularity. Staples uses it (their "SparX" group), and much more notably a Clojure service is used to process every single transaction in Walmart stores.


Can you or is there anything more to say about that Clojure service/Walmart? That sounds fascinating.


It was mentioned in passing at Clojure/West a few months ago. I wish I remembered more...this video might have more details: https://www.youtube.com/watch?v=av9Xi6CNqq4&list=PLZdCLR02gr...


Scala is getting big in the enterprise. This list http://www.quora.com/What-startups-or-tech-companies-are-usi... gives a small overview


Typesafe is contributing greatly to that list. http://www.typesafe.com/resources/case-studies-and-stories


Yup! I did a research while ago (end of 2014). Scala was by far the most used among the other choices (Clojure,Haskell,F#).


Scala is not a functional programming language, it is OO first and foremost. It has better support for functional programming than Java 8, Python or Smalltalk. And that in itself is great.


Java 8 has lambdas and lots of streaming functional comprehensions like map, filter, fold etc.

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'?


Yes Java 8 does have a lot of new functional goodness. But it's still missing a lot even compared to Scala. For example I cannot even do a basic case analysis without involving statements, you have the ternary operator for working with expressions and that's about it. Static type systems, type inference and algebraic datatypes, which I believe to be hugely beneficial, do not define "functional programming" in most peoples minds.


It's more functional than most languages called "functional".


Haskell usage by enterprises can be found here: https://wiki.haskell.org/Haskell_in_industry


Scala and F# are probably the most popular enterprise choices. Both connect well to existing infrastructures (JVM, .NET), are relatively easy to train new developers on, and have largish companies backing them.

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.


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 ...


Not a secret -- at Monsanto (Fortune 200) we use Scala heavily now, starting from one project in 2010 and now a dozen teams use it for many many production projects internally and in AWS. Certainly some in the almost 200k LOC range. Scala is replacing Java at Monsanto (and yes we're always hiring!)

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.


Scala is gaining popularity because of Spark https://spark.apache.org/


Clojure's all the rage at the moment.


Walmart Labs is using Scala for their data science work, according to Julia Greissl, whose talk I saw in Seattle a few days ago.


If you consider Scala functional, I think it wins the popularity contest: used by startups and established companies (Linkedin, Twitter, Meetup, Verizon, Morgan Stanley, Autodesk, HuffPo, etc, etc...) and is not "we use it in a dark corner where nobody cares" and more like "betting the whole farm on it".


I would "bet the whole farm" on Haskell before 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.


Sure, I understand, for some orgs, betting on Haskell is the best choice. What I meant is that they're not using Scala in a small obscure project that nobody cares/know (as most early adoptions of languages are in big companies), they have a significant amount of code and their main business runs on it. (I'm not talking about the ideal case/what I would like, I'm talking about what I've observed in my bubble )


Does Scala have "compile speed issues" compared to Haskell? That's probably my biggest pain point using Haskell day-to-day.


No. Scala neither needs to compile dependencies, nor does it need to recompile everything on a change.

The first compile might take a bit, but after that all changes are usually incrementally compiled in less than a second.


> Then you have the compile speed issues, the problematic tool chain [...]

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.


> Did you ever use Haskell? Those issues are far worse in Haskell than in Scala.

I've used both, if anything Haskell is a little faster.

> 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.

FUD. This is simply not true.


Thank you for attacking that misconception. Haskell is, at this point, a very practical language, and becoming increasingly that way over time as it proves to have the best enforcement model for the functional style among the options out there. For good and bad, we're not in the 1990s anymore.


That gave me a good chuckle.


At my company (publicly traded; >200 engineers) I know that Scala has begun to be picked up by the Java people. We're also rolling out Storm (Clojure) but I don't know if there's anyone actually writing Clojure code.


Elixir might pick up some mind share, similar to ruby but still keeps its erlang roots.


I don't think it's quite there, yet. Everything's in place, and Elixir is a wonderful language, but it hasn't been quite battle tested yet.

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.


> 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.


You might be right about Groovy. I've seen JRuby used pretty heavily in enterprise environments, though (usually to integrate Rails with an existing Java-based system).


For context I work for publicly traded multinational real estate portal with about 1000 employees.

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.


Scala, Clojure, and Erlang come to mind. F# is another possibility, since .NET/CLR is becoming increasingly popular in the enterprise (particularly in Windows-heavy datacenters), though I don't know of a whole lot of enterprise F# deployments off the top of my head.

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.


Why hasn't haskell become popular?


The language is more restrictive and sometimes it's harder to get something working. Of course the payoff is immense, you end up with much more maintainable and composable code. However I'm not convinced that many enterprises care much about these properties, as they are often more of a long term win. People also have an emotional attachment to their existing tools and paradigms.


"Of course the payoff is immense, you end up with much more maintainable and composable code. However I'm not convinced that many enterprises care much about these properties, as they are often more of a long term win"

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.


Well their idea of maintainable is different. They often worry about having to hire intelligent programmers versus whatever mass produced workers.

Same thinking that leads to not using type inference because it's "harder to read".


> 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

I would be very surprised if there were not tens of companies with 200kloc+ Haskell codebases. I know that one of them is an enormous enterprise (but the others that I know of are not).


What company? I would like to know.


Standard Chartered.


I never compared enterprises to startups. I also wouldn't want to generalise. Some enterprises I know have millions of lines of Python code. Personally I'm skeptical that such a codebase is going to be maintainable and that they even 'care a great deal'.


Very steep learning curve. Months to years to become good at it rather than the weeks to months of the Java/C# style enterprise languages. Needs a more "math like" mindset rather than a step-wise stateful mindset like typical imperative programming languages. If you're not good at abstract math you may never get comfortable with Haskell.


Have you seen C++14 or the complexity of Java stacks like Spring? These also take months or years to learn. At least learning some new abstract math is knowledge that will be useful for the rest of your life.


I agree with you and have said that in the past myself. However, most people know at least one imperative language already and that gives them a big step up in learning the frameworks. Learning Haskell is like starting over from scratch. And, at least for me, having completed an undergraduate hard science engineering degree, I'll never be good enough at math to really grok Haskell like I do many of the imperative languages. I'd make a rough guess, based on my observation, that for every 100 imperative programmers for whom the programming language just "flows" that only one or two will get that comfortable with Haskell.


IMHO if you are smart enough to complete an engineering degree you are easily smart enough to grok Haskell. It really is quite a simple language (compared to C++ and Scala anyway). Of course, like me, you might not grok everything that other people do with Haskell, but this is true for any language. I agree that Haskell is very different from imperative languages and that there can be a lot to learn before you can become productive.


Probably platform I would say. Hard to compete against languages that fit pretty naturally into an existing Java or .NET ecosystem. I'm referring to Scala, Clojure, and F# of course. It is definitely "popular" in some other senses though.


I think that it's self-reinforcing.

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.


What I would like to see happen is less use of general purpose programming languages; and more use of domain specific languages. DSLs give less opportunities for people to shoot themselves in the foot and more possibilities for heterogeneous hardware, parallel programming, static analysis etc. Of course, a small percentage of us will have to write these DSLs and Haskell IMHO is currently the best tool for this.


If you consider it functional, Common Lisp is still used by some very large and established companies: the Lisp HUG mailing list (LispWorks) will frequently have email signatures from some of them. There is some truth to the notion that CL is a competitive advantage and so its use tends not to be discussed in the open.


None, or possibly Haskell.

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.


The critical distinction here is popular with the people who have to use it or most widespread? :-)


Many have already said it, but Clojure seems to be gaining in popularity.


Surprisingly, I think Clojure has much more traction than Scala.


Can you please elaborate?


None.


AlbozZ


I guess you'd need to define what you mean by functional language. That term gets thrown around a lot, to the point of meaninglessness. If you mean referentially transparent then neither Scala nor F# are referentially transparent.


I've often seen the term "functional first" used, which would describe F# but not Scala.


Javascript / Nodejs

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?


All I can think is... Poe's Law.

https://www.youtube.com/watch?v=ztVMib1T4T4


I was like wait what...Then I saw your comment.

Yup Pretty much same reaction to that suggestion.


A CoffeeScript coder who apparently doesn't like JavaScript.


No IO in Haskell is purely functional. Your Haskell program wires up a computation that is eventually run by the runtime. The wiring up, as described in Haskell, supports referential transparency and composition as only pure code can. Your confusion may arise from people using the term "pure" to differentiate from "monadic".


All I meant is IO (aka input/output) can have side effects outside of the scope of the language environment. Haskell has the IO type to encoding those this side effects: https://wiki.haskell.org/Introduction_to_IO


I haven't decided yet, check out this link to decide for yourself:

https://leanpub.com/purescript/read#leanpub-auto-the-eff-mon...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: