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.
If this question can be reworded to fit the rules in the help center, please edit the question.

Valid question but rather - either change to Community Wiki or restrict your question to threading implementation.
–
David NealeMay 21 '10 at 8:51

1

i think if you define the qualities youre looking for instead of just saying "bad" it would be less subjective
–
Andrew BullockMay 21 '10 at 8:51

1

Processes are more expensive than threads. I dont see your point.
–
leppieMay 21 '10 at 8:59

@leppie: when the OP says 'processes', he's not referring to OS processes. He's referring to Erlang processes, which have no real correlation to OS processes, and are much more lightweight than .NET threads.
–
pblasucciMay 21 '10 at 11:59

3 Answers
3

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

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.

Why the down vote? Whether the processes/tasks are implemented using threads doesn't matter - either the quality of the implementation, or the expressiveness of the language would be better reasons to distinguish them.
–
Pete KirkhamMay 21 '10 at 9:11

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:

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.