23

I've been putting time into learning functional programming and I've come to the part where I want to start writing a project instead of just dabbling in tutorials/examples.

While doing my research, I've found that Erlang seems to be a pretty powerful when it comes to writing concurrent software (which is my goal), but resources and tools for development aren't as mature as Microsoft development products.

F# can run on linux (Mono) so that requirement is met, but while looking around on the internet I cannot find any comparisons of F# vs Erlang. Right now, I am leaning towards Erlang just because it seems to have the most press, but I am curious if there is really any performance difference between the two systems.

Since I am used to developing in .NET, I can probably get up to speed with F# a lot faster than Erlang, but I cannot find any resource to convince me that F# is just as scalable as Erlang.

I am most interested in simulation, which is going to be firing a lot of quickly processed messages to persistent nodes.

If I have not done a good job with what I am trying to ask, please ask for more verification.

afuzzyllama
  • 367
  • 1
  • 2
  • 11
  • 13
    Languages don't have speed. Specific language implementations running a specific program on a specific input (this may include the whole outside world, depending on the program) have a speed. –  Dec 04 '11 at 16:43
  • 1
    F# runs on the .NET runtime and Erlang runs on its own VM. Erlang's processes are considered to be lightweight vs languages that are in its domain (like Scala). For a simulation spawning nodes and passing a lot of messages, is the .NET/Mono runtime just as good as Erlang's VM or is Erlang's VM superior? – afuzzyllama Dec 04 '11 at 16:45
  • 3
    @delnan: Languages do have performance characteristics. – J D Feb 23 '12 at 14:05
  • 2
    @JonHarrop How so? A programming language is merely some syntax and associated semantics. –  Feb 23 '12 at 14:08
  • @afuzzyllama Can you just stress more on your application. just like the general purpose, size of the data, number of iterations, real-time or deferred, processing time on a normal desktop for a task.If its intended to be a numerical crunching tool, then it would be really slower in Erlang (not sure about F#) when compared to C,C++. You can still connect to C,C++ from Erlang to speed up code. Erlang is at its best in message parsing involving lot of agents. – Ubermensch Feb 23 '12 at 14:28
  • @afuzzyllama Number-crunching don't go well with functional programming (I don't believe it) due their evaluation model. In FP, you specify what is to be done and not how it is to be done. So it is always slower than imperative languages. Yet, Erlang is a real good choice (I am also learning it for a simulation application along with Python) for parallel processing and it does provide backports to C,C++. And going by your question, it looks you are going to create pure functions for simulations that could be run in parallel and results get aggregated at the master node. Am I right? – Ubermensch Feb 23 '12 at 14:35
  • @Ubermensch: "Number-crunching don't go well with functional programming". Although there is some truth to that statement (i.e. performance often requires mutable arrays) there are many important cases where FP is performant. In particular, when functions crunch small value types such as ints, floats, complex numbers and tuples of them then FP is optimized for this case and can even outperform IP, e.g. FP implementations optimize multiple return values with a calling convention that uses registers rather than sret. – J D Feb 23 '12 at 15:39
  • @Ubermensch - While I have moved onto other things since asking this question, the idea of the application was to be an interactive simulation. Think of a wolf/bunny AI scenario where players could be hunters. The idea was to have each actor in the simulation be autonomous and just to have fun from there! – afuzzyllama Feb 23 '12 at 16:59
  • @JonHarrop The logic with FP is what needs to be done. How it is to done is determined by the underlying FP machine. In case of C/C++, you specify what and how to do and the compiler turns into assembly code. So you can optimize code(the same can be done in FP but it just defeats its very purpose of elegant problem solving). Also, contiguous memory layout is the preferred way for huge number-crunching. FP is really great but for number crunching a few functions need to be optimized and the percentage of FP in HPC being relatively low, IMHO, it needs to pick up – Ubermensch Feb 24 '12 at 04:18
  • @afuzzyllama For simple simulations, you can get up and running with garlicsim and simpy (python) if you want to learn simulation. As a long-term option your selection of Erlang is superb and you can better do message-parsing in Erlang and number-crunching in other languages by having a lot of tiny actors. This is a long-term solution and I believe its tough but you can do it with your perseverance. – Ubermensch Feb 24 '12 at 04:21
  • @Ubermensch: FP is used in HPC but rarely for number crunching. FFTW is written in OCaml. Some of the world's largest symbolic computations (e.g. Feynman diagrams) on supercomputers have been done using OCaml. F# has good control over memory layout. But I suspect you're talking about purity rather than FP. – J D Feb 24 '12 at 11:18
  • 1
    @delnan: Semantics place limitations on optimization. For example, dynamically-typed languages are prohibitively difficult to optimize in practice. The lack of value types on the JVM results in a lot more heap allocation than on .NET and, consequently, much greater stress on the GC. Like code generators, garbage collectors can and do exploit information like immutability in order to improve performance. The design of a programming language has a huge effect on this. – J D Feb 24 '12 at 11:22
  • @JonHarrop Your info on Feynman diagrams is new to me and thanks for the input (would be better and helpful if you could provide me references for FP in HPC). FFTW looks to be in C(I checked at http://www.fftw.org/). Your suspicion is right. I believe FP must be in its place (pure functions based on lambda calculus) and others in theirs. You can mix both paradigms to make great software but I generally don't like the notion of function with classes. Your suspicion is right. – Ubermensch Feb 24 '12 at 11:34
  • @JonHarrop Of course semantics put *some* limit on optimal and practically feasible implementation cleverness. But this still leaves **huge** ranges in which the acutal performance can lie. To know how many seconds something takes, you have to specify **what** you're doing and **how** you're doing it, i.e. the program and the implementation. A compiler may optimize arithmetic but ship with a runtime that's very bad at I/O, while an interpreter for a dynamic language may have a highly optimized I/O library, and depending on which you choose for what program, you'll get vastly different results. –  Feb 24 '12 at 13:35
  • 1
    @Ubermensch: The Feynmann diagrams work was by Dr Thomas Fischbacher, IIRC. FFTW is primarily OCaml source code that generates C code (which is often distributed to avoid the dependency on OCaml). Many people often use FP to mean extensive use of higher-order functions rather than purity (controlled side-effects). That kind of FP has many uses in number crunching and is even seen in Fortran. Purity is less useful there for the reasons you gave. – J D Feb 24 '12 at 13:53
  • @delnan: In this context, knowing that Erlang is dynamically typed and F# is statically typed you can immediately hazard an educated guess that procedural code will be much faster in F# which is indeed the case. – J D Feb 24 '12 at 14:01
  • 1
    Really good question! I like and use F# but I'm also interested in Erlang, I like the idea and syntax but I still can't find the point of Erlang :( – cnd Apr 10 '12 at 07:14
  • There is an Erlang implementation in [Erlang.NET](https://github.com/takayuki/Erlang.NET) – Martin Tapp Jun 10 '13 at 20:19
  • F# can run on linux but mono isn't as mature as the MS version. If performance is that important to you, I would check out the benchmarks game or write some of your own before making a decision. – stonemetal Jun 10 '13 at 21:36

3 Answers3

24

What do you mean by "viable?" "Having the most press" is not necessarily the best way to choose a language.

Erlang's claim to fame is its capability of massive parallelization. That's why it's commonly used in Ericsson phone switches. Erlang is soft-realtime, so you can make certain performance guarantees about it.

F# benefits from the optimization capabilities of the .NET Jitter. In addition, the language itself is designed to be a high-performing functional language (it being a variant of OCaml, widely used in the financial industry because of its speed).

Ultimately, unless you plan on running millions of tiny agents at the same time (which is what Erlang is optimized for), F# should be up to the task.

This page explains the appropriate use cases for Erlang.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • By "viable" I meant scalable. I know that having press doesn't mean that that language in necessarily better, but it seems that Erlang has been proven (at least by Ericsson). What do you mean by agents? Processes? – afuzzyllama Dec 04 '11 at 16:55
  • 1
    Yes. Erlang has been proven to handle many phone calls on an Ericsson switch at the same time. You have to figure out if your use case is similar. I see that as a relatively specialized use case; if this characteristic is absent in *your* application, I don't see any advantage to using Erlang, and the Erlang page actually describes some use cases for which Erlang is *not* suitable. – Robert Harvey Dec 04 '11 at 16:59
  • 2
    Agents, actors, it's a design concept that comes up a lot in functional language discussions; I'm surprised that you haven't run across it yet. http://en.wikipedia.org/wiki/Agent-based_model – Patrick Hughes Dec 04 '11 at 17:02
  • In other words, do you need *massive* scalability (either now or eventually) of the kind Erlang provides? Most programs do not. – Robert Harvey Dec 04 '11 at 17:02
  • @RobertHarvey - The optimist inside of me would hope that one day I would be writing a program that needs massive scalability, but in reality probably not. I think I'll look into F#. Thanks. – afuzzyllama Dec 04 '11 at 17:04
  • @PatrickHughes - I've run across actors, but I didn't read the agent page yet. Thanks for clueing me in! – afuzzyllama Dec 04 '11 at 17:05
  • 1
    F# also has the agent model - using the slightly cryptically named ['MailboxProcessor'](http://msdn.microsoft.com/en-us/library/ee370357.aspx) which is the same sort of thing as in Erlang. I can't comment on the relative performance characteristics of each though. – FinnNk Dec 04 '11 at 18:15
  • @RobertHarvey It's a bit misleading to say that F# or OCaml are "widely used in the financial industry because of their speed". In HTF, millisecond-latency applications, Linux and C++ are the platform of choice. Also, in cases where a managed language is used, I would still expect huge optimizations to be in place, including replacing standard libraries and writing directly in IL. – Sklivvz Jun 11 '13 at 07:36
  • @Sklivvz: I think you read more into that statement than it actually says. – Robert Harvey Jun 11 '13 at 14:43
  • @rob probably, in fact I did say misleading :-) – Sklivvz Jun 11 '13 at 14:45
  • Erlang is perhaps rather more known for its concurrency as opposed to parallelism. Further, soft-realtime systems do not necessarily require worst-case guarantees, which is the main thing distinguishing them from hard-realtime systems. Games are another great example of soft-realtime systems. – awdz9nld Dec 08 '15 at 15:29
  • If you're looking for the highly concurrent agents with OTP style stuff for fsharp, please check out Akka.net http://getakka.net/ – BeardedO Sep 07 '16 at 22:54
8

Few objective statements can be made on this subject because the performance of these two languages is strongly dependent upon the application and programming style.

The only advice I can give is that F# has the performance advantage of a static type system and the CLR does a good job leveraging this in order to improve performance. F# does have asynchronous agents and message passing but it has not been optimized and synchronous code is often over 10× faster.

Erlang is dynamically typed which puts its at a significant disadvantage in terms of performance (expect a lot more boxing) but it was built from the ground up to support fast message passing between asynchronous agents so that may well be a lot faster than the equivalent F#. However, I have no benchmark results to back this up: it is just my expectation.

As an aside, both Erlang and F# are relatively fringe languages with small communities and, due to their different target markets, people familiar with both are rare. The only person I can think of who nearly qualifies is Jesper Louis Andersen but I'm not sure how much F# he has done.

J D
  • 2,332
  • 24
  • 17
6

You should read this post by Joe Armstrong: http://erlang.org/pipermail/erlang-questions/2012-February/064277.html

The short of it is that Erlang was not designed to be fast! It is reasonably fast in many cases but that is secondary to issues like fault tolerance and stability.

The truth is both Erlang and F# are nice languages, and while I have only taken a quick look at F# I have written a book on Erlang: Building Web Applications With Erlang and I can say that it is a fun language to work in.

I would also point out that there seems to be a boom in functional language books to be published in the next 6-9 months. I know of at least 4 on Erlang (including mine), One on Haskell, as well as Titles on OCaml, Clojure and F#.

Zachary K
  • 10,433
  • 2
  • 37
  • 55