As an example, see here: https://bazqux.com/ and the discussion is here: https://news.ycombinator.com/item?id=5961570

He was able to survive unexpected slashdot effect from being on the front page of Hacker news without even noticing it. He told me he went up one evening and found that there were tens of thousands of new users actively trying his site. So he added a couple of servers and went to sleep.

GHC development is very active.

And the answer to your last question is No.

I think delays weren't that noticeable then.

There are two active areas of development which could solve this problem (long pause times with a large working set):

* Compact regions -- which will provide off-heap storage that can be manually memory managed. These are shipping with GHC 8.2. See the paper here if you're interested: http://ezyang.com/compact.html

* Linear types -- A type system extension which allows the programmer to specify values which can only be used a single time. This allows a king of type-safe manual memory management where the compiler statically check that values are freed. This work is further off, but there is currently a prototype being developed in GHC. Check out this blog post for more information: http://blog.tweag.io/posts/2017-03-13-linear-types.html

> Would it be possible to efficiently run Haskell using Go's runtime environment, i.e. by changing the compiler backend?

It's an interesting thought, although I suspect this would be very challenging in practice. Haskell's lazy evaluation, with thunks instead of concrete values, probably wouldn't play nicely with Go's heap layout. I would also suspect Go's runtime has been quite special-cased to Go the language. It would nice if the Go runtime system was opened up in the same way the JVM is.

At this point it might be simpler to translate Haskell source syntax into Go.

My overall feeling is that putting more work into the standard GHC runtime system would be a more efficient use of time.