"Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for.
I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.
The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.
Servo is doing some things to outsource GC to JavaScript, because the DOM (and therefore object lifetime tracking) needs to interact tightly with both JavaScript and native code:
What are the limitations here? I'm quite a bit surprised you're able to make this work properly with pthreads... I somehow thought the GHC runtime will automatically multithread pure functions that can be evaluated in parallel.
How much can you call back into C from a Haskell function and have things behave reasonably? I suppose there's actually a bit of advantage in that such a thing would need to return a type in the IO monad, but I'm super unfamiliar with the GHC runtime.
I am not aware of any limitations, except for the static linking caveat noted in the README. The build process is also a bit involved; see the Makefile for details.
My use case involves shipping Haskell plugins for C programs to end-users, without requiring any Haskell to be installed. Hence, statically linking all Haskell libraries into the plugin binary. On Linux, this is slightly inconvenient, as GHC packages are not usually compiled with -fPIC, so some recompilation is in order. On OS X, all code is always position-independent.
As for your other question — calling C from Haskell is very easy, and there is a lot of examples.
Sure, I've played with Haskell-to-C FFI before (a very tiny bit). I'm curious if there are some complications with C->Haskell->C, but maybe not.
I'm strongly thinking that Haskell has an advantage here because "well, what if the Haskell function fails" or "well, what if the C function fails" is well-defined by the type system....
Can you return a pointer/reference to a Haskell object to C on one thread, and then call Haskell functions on it from another C thread?
Yes. You can use stable pointers for this purpose.
A stable pointer is a reference to a Haskell expression that is guaranteed not to be affected by garbage collection, i.e., it will neither be deallocated nor will the value of the stable pointer itself change during garbage collection (ordinary references may be relocated during garbage collection). Consequently, stable pointers can be passed to foreign code, which can treat it as an opaque reference to a Haskell value.
This is a great comment, and very much in line with my experience. The tightening of Rust's focus over the last year has been really impressive, and I think it has become more of a great language for a few things than a good language for everything.
I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.