You may have seen the Some Were Meant for C polemic; I do not agree with it completely but I encourage you to read it if you have not. Here, I give some comments on ATS and Rust in light of it.
It's no secret that Rust tends to have better performance than Haskell. This comes at a cost: Rust is far less expressive than Haskell and writing efficient Rust (like writing efficient C) usually means skirting abstractions.
With C (and consequently ATS), this is made up for by the fact that a C library can be called from essentially any other language. You can write an implementation of the totient function, which is around 1.75 times faster (as an FFI call) than the equivalent in Haskell - not particularly impressive given the abstraction you give up writing imperative code, but made much more palatable by the fact that the library could be called from Ruby or Python as well.
Part of that is due to existing support for C FFI. But part of it is due to the design of the languages in question. And that is where ATS is unique: unlike C, it can guarantee memory safety; unlike Rust, it gives fine-grained control of memory.
This fine-grained control of memory is what makes passing data structures between languages possible1 - and it is an area where Rust notably fails to deliver. Its design simply does not allow the same fluent (high-level) inter-language communication via memory that characterizes systems programming.
It is a mistake to say that Rust's speed is not a consequence of its design. But it is equally a mistake to say that Rust's speed is meaningful in a vacuum.1: In the case of ATS, the advanced type system also contributes: we can call Haskell sum types or universally quantified types, for instance.