Meanwhile, a lot a people hate on C++, which they're only able to do because they learned its nuanced spec, which they only did because it had already reached critical mass in the wild, because it worked everywhere and was, despite the complaints, comprehensible, if hard to get perfect in the language-lawyer way.
(I don't have any particularly strong opinions on Windows myself; it just seemed an apropos example for the Hacker News crowd. There are a million other examples of the same type, of course.)
Something that isn't used at all (or much) has very low utility.
To my (C-tainted ears), the affirmations of support generally tend to sound something like, "It's better because its (modern|buzzword|safer|buzzward|technobabble|compact)."
I am not suggesting that these languages do not have tangible benefits, but I do wish their supportors would be a bit more concrete while describing them.
Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell programmers that want their library to be widely used may start greenfied projects in Rust instead of Haskell.
You are looking at it from a Haskell -> Rust conversion cycle, when that isn't really important from either a numbers standpoint or how Rust is positioning itself.
Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturity and library ecosystem that Haskell currently has.
One might catch a few people who absolutely need manual memory management, I guess, but my experience is that this is often an excuse and those who are seriously interested in using another language find ways around the problem. For OS kernels and the like Rust has an advantage, but again that's a tiny niche. Rust's C FFI might be a bit better, but honestly Haskell's is rather good; I can't see that making the difference. And if you find the safety or the type system compelling, surely you've already moved beyond C++.
I'd like to be wrong - I'd like to see C++ programs moving into better languages. But I think a need for manual memory management is very rarely the real reason people are still using C++ - and if it's not that, what can Rust offer that wasn't already available?
Rust has emphatically never been "Haskell with manual memory management". That conception is entirely incorrect, typeclasses or no. If you must frame Rust in terms of prior languages, consider it to be an ML with an extreme focus on zero-cost abstractions and pervasive, memory-safe concurrency.
When will Rust be pushed by an OS vendor?
That seems to be the main selling point for Rust, anyhow. Zero cost abstractions, predictable data sizes, well defined memory scopes, etc.