That's kind of a false dichotomy, as these languages are applied to different problems.

Speaking of the garbage collector, it was the biggest productivity boost that software developers ever experienced and no matter how many tricks the Rust compiler pulls, the hit on productivity is real. And in terms of the "if it compiles, it runs" feeling, that comes with having an advanced type system. Rust pulls some really nice tricks, but cannot match Haskell. And again, the lack of a GC means the compiler's budget is spent on ensuring that the code is memory-safe, with other things having much lower priority.

> Rust pulls some really nice trick, but cannot match Haskell.

I'm not convinced that's true. Rust is even stricter than Haskell in many respects (first example that comes to mind is incomplete pattern matches, which is a compiler error in rust) and strictness also avoids some run-time errors. I've managed to produce infinite loops in Haskell by accidentally defining recursive values more than once.

While I agree with you about pattern matches in Haskell but for completeness sake there is a ghc flag -W for it. If you compile this code with that flag, you will see the result below:

  --hello.hs
  f mx = case mx of
        Just x -> x
        --Nothing -> "NA"

  main = do
    let v = Just "5"
    putStrLn $ f v

  ghc -W hello.hs
  [1 of 1] Compiling Main             ( hello.hs, hello.o )
  hello.hs:1:8: Warning:
    Pattern match(es) are non-exhaustive
    In a case alternative: Patterns not matched: Nothing

In my opinion, incomplete pattern matches should be an error not a warning, but it seems strange to choose a different language based on that issue.

GC should never be a "torn between" factor. Either you have a hard requirement that makes GC unusable, or you don't.

Have you seen the mio library for async IO in Rust? I haven't used it myself, but everyone that I've asked has had nothing but glowing praise for it (though it doesn't yet support Windows): https://github.com/carllerche/mio

I've used mio and I also have nothing but praise for it, but it is a fairly thin abstraction over epoll/kqueue. That's certainly useful, but it's not nearly as nice or easy to use as the green threads that haskell gives you.

(That being said, I think 'woeful' is a pretty strong word to describe the situation. Sure, Haskell is nicer in that regard, but most other languages aren't.)