Is F# a poor choice for a functional language [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

To me, I think F# is a bad choice due to the fact that it uses threads behind the scenes. To me, threads are too "heavy" due to things like context switching开发者_运维知识库.

I can see why Erlang is a good choice because it uses light weight processes.

Am I wrong?

---

I don't understand what you are asking.

F# does not use 'threads behind the scenes', or at least no more than any .NET process does. In fact F#'s async facilities make it much easier to write non-blocking I/O programs that do not consume threads (as compared to C#/VB which has a more difficult threadless/non-blocking programming model).

(And, of course, typically you don't just pick one arbitrary aspect to compare two things and then decide 'X is better than Y'. There is more to a programming language than just a threading/process model.)

You may enjoy reading

http://blogs.msdn.com/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

The final three paragraphs are worth quoting:

Indeed, there are few other .NET or JVM-based languages that support lightweight reactive agents at all – in early .NET it was said to be “impossible” because of the costs of threads. In this context, F#’s integration of “async { ... }” in 2007 can be seen as somewhat of a breakthrough in applied language design – it allows lightweight, compositional async programming and reactive agents in the context of an industrially accepted and interoperable programming platform. Along with the Axum language prototype (which has been influential on F#), F# has proven that an asynchronous language feature is a feasible way to break through the logjam of “do we make threads lightweight or not” that currently bedevils industrial runtime system design.

F# async programming can be seen as an implementation of resumptions, and there are many precursors here, for example OCaml delimited continuations, Haskell embeddings of monadic concurrency and papers emphasising the importance of resumptions with regard to concurrency.

You can use F# asynchronous agents on .NET 2.0, 3.5, 4.0, on Linux/Mono/Mac and on Silverlight. Indeed, you can even use F# async programming when F# is translated to Javascript using the WebSharper platform. Enjoy!

---

Since 2006 erlang has had SMP, so it too 'uses threads behind the scenes'. Neither a process in erlang nor (AFAIK) asynchronous tasks in F# correspond to an OS thread; both runtimes use threads as and when required, and lighter-weight mechanisms where appropriate.

---

If you want to get some useful feedback, you should specify the scenario you are interested in. However, functional programming isn't about threads or processes - it is more about expressing algorithms and using different programming patterns, so the use of threads/processes is a really weird criteria for comparing functional languages.

Most importantly, in F# concurrent programming is just a matter of library and there are many choices:

• F# async mentioned by Brian allows you to implement light-weight message-passing concurrency
• PLINQ allows you to write declarative data-parallel computations
• Tasks give you a fine-grained primitive for executing a large number of small tasks in parallel
• Threads (used rarely) give you the full control over closer to the operating system level

On the other hand, Erlang pretty much forces you to use a single library for concurrent programming (which is directly supported by the language). That may be a good choice for many areas (such as telecommunication applications), but it may be too restrictive for some other cases.

I'm not saying anything bad about Erlang - you can certainly use it to encode many other higher-level concurrent programming paradigms as well. I'm just saying that binding the language to a single concurrency programming model (and using this to compare the languages) is a wrong approach in general.