There's a ton of people who aren't using Haskell and never will. It is a great language, but it isn't a language that will ever be really popular.
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.
Let me put it this way then: why would someone using C++ who will be willing to migrate to Rust in the future not be willing to migrate to Haskell now?
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?
The people sticking to C++ aren't using it for the sheer joy of manual memory management, they're using it because they either require or enjoy the ability to exert predictable control over programs in terms of both execution speed and memory usage. Haskell, being a lazily-evaluated garbage-collected language, offers little to these people.
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.
Many of those C++ developers are using it, because C and C++ are the only languages with native compilation toolchains that all OS vendors have on their SDKs.
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.