If you bought a functional programming paradigm, chances are that you like both Erlang and Haskell. Both have purely functional cores and other goodness, such as light streams, which make them suitable for a multi-core world. But there are differences.
Erlang is a commercially proven fault tolerant language with a mature distribution model. It has a unique feature in its ability to update its version at run time by loading hot code. (Calmly!)
Haskell, on the other hand, has the most complex type system of any main language. (Where I define "mainstream" as any language that has an published O'Reilly book, so Haskell counts.) Its straightforward, single-threaded performance looks superior to Erlang, and its lightweight streams look even easier.
I am trying to build a development platform for the rest of my coding life and wondered if Erlang and Haskell can be mixed to achieve a best-in-class platform. This question has two parts:
- I would like to use Erlang as a kind of fail-safe MPI for gluing instances of the GHC environment. There would be one Erlang process at runtime of the GHC. If "the impossible happened" and the GHC runtime died, the Erlang process will detect this somehow and die. Erlang hot code loading and distribution functions will continue to work. The GHC runtime can be configured to use only one core or all of the cores on the local machine, or any combination between them. After the Erlang library has been written, the rest of the Erlang-level code should be purely a template and automatically generated for each application. (Perhaps, for example, using Haskell DSL.) How to achieve at least some of these things?
- I would like Erlang and Haskell to share the same garage collector. (This is a much deeper idea than 1.) Languages that run on the JVM and CLR reach more mass by sharing runtime. I understand that there are technical limitations on running Erlang (loading hot code) and Haskell (a higher type of polymorphism) on the JVM or CLR. But what about decoupling only the garbage collector? (Sorting start of execution for functional languages.) The distribution would obviously have to be really fast, so perhaps this bit should be statically linked. And there must be some mechansim to distinguish a volatile heap from an immutable heap (including a lazy write once of memory), as the GHC needs it. Would it be wise to modify both HIPE and GHC so that garbage collectors can share heap?
Please respond to any impressions (positive or negative), ideas or suggestions. In fact, any feedback (without direct appeal!) Is welcome.
Update
Thank you for all 4 answers today - everyone taught me at least one useful thing that I did not know about.
Regarding the rest of the coding thing of life, I turned it a little on the cheek to provoke controversy, but actually it is true. There is a project that I mean that I intend to work until I die, and he needs a stable platform.
In the platform that I suggested above, I would only write Haskell, since the Erlang template will be created automatically. So how long will Haskell last? Well, Lisp is still with us and it doesn't look like it is leaving soon. Haskell is open source BSD3 and has reached critical mass. If programming itself continues after 50 years, I would expect Haskell or some continuous evolution of Haskell to still be here.
Update 2 in response to a rvirding message
Agreed - Implementing the full universal Erskell / Haslang virtual machine may not be completely impossible, but it will certainly be very difficult. Separating only the garbage collector level, like something like a virtual machine, although it’s still complicated, sounds an order of magnitude smaller than it’s harder for me. Functional languages should have much in common in the garbage collection model — the uniqueness of immutable data (including thunks) and the requirement for very fast distribution. So the fact that the community is closely related to monolithic virtual machines seems strange.
VMs help achieve critical mass. Just look at how "lite" functional languages like F # and Scala took off. Scala may not have Erlang's absolute resiliency, but it offers an escape route for so many JVM-bound people.
If there is one heap, the message passes very quickly introducing a number of other problems, mainly that the GC makes it more difficult, because it must be interactive and globally without interruption, so that you cannot use the same simple algorithms as the model of the process heap.
Absolutely, that makes perfect sense to me. Very smart people on the GHC development team seem to be trying to solve part of the problem with the parallel GC "stop the world".
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf
(Obviously, "stopping the world" will not fly for General Erlang, given its main use case.) But even in cases where "stopping the world" is in order, their accelerations do not seem universal. Therefore, I agree with you, it is unlikely that there is a universally better GC, so I pointed out in the first part of my question that
GHC runtime can be configured to use only one core or all of the kernels on the local machine or any combination in between.
Thus, for this use case, I could, after benchmarking, select the Erlang path and start one GHC run time (with single-threaded GC) plus one Erlang process per core and allow Erlang to copy memory between the kernels for good locality.
Alternatively, on a dual-processor machine with 4 cores per processor with good memory bandwidth on the processor, benchmarking may suggest that I run one GHC runtime (with parallel GC) and one Erlang process per processor.
In both cases, if Erlang and GHC can share a bunch, sharing is likely to be associated with a single OS thread running on the same core. (I'm going out of my depth here, so I asked a question.)
I also have another agenda - comparative functional languages, regardless of the GC. Often I read OCaml v GHC v Erlang v ... test results and wonder how the results are mixed with different GCs. What if the choice of GC can be orthogonal to the choice of a functional language? How expensive is a GC? Watch this Devil Lawyers Blog Post
http://john.freml.in/garbage-collection-harmful
my friend Lisp John Fremlin, whom he charmingly gave his post: "Automated garbage collection is garbage." When John claims that the GC is slow and has not actually accelerated that much, I would like to be able to withstand some numbers.