For starters, there are the typical complaints about compile time and the resulting IDE experience (which depends on rustc for now, an on demand driven compiler frontend is WIP).
The syntax (as much as i hate people who focus on it as their only complaint). I heard it was different in ancient times but they changed it to appeal to c(++) devs more. It just sucks that the world can't seem move on from C-ish syntax. Rust is sometimes a bit noisy since its whole point is that it has more information about memory and mutability (a lot could be infered but it serves as docs and provides more localized errors) so if it has explicit lifetimes and references, it could at least cut down on {} and (). Something more pythonic or haskellish would be awesome. There could even be automatic converters like there are for style currently. You could write curly braces if you insist on them and then have it formatted to use indents. Or you could only format when commiting. Some people seem to hate indent based blocks but I have never heard a technical reason why it shouldn't be possible. I pretty much haven't even heard anyone else proposing it.
Infix functions would be awesome `v1 dot v2` is much better than `v1.dot(v2)`. Kotlin has them.
Semicolons - kotlin shows you can have an expression based lang and not need semicolons (though it doesn't have implicit return of last expr, maybe that makes it ambiguous, though i doubt it, kotlin has implicit return in lambdas afaik).
The syntax has some
dark corners around bit ops and patterns. Similarly
https://github.com/dtolnay/rust-quiz will break your hope in rust or humanity's ability to design decent langs (at least clippy warns on a lot of those).
Enum variants are not their own types. I know it would be messy to implement properly (i guess in a way it's subtyping) and that's why it's not been done yet but haskell does it afaik. You run into it when writing compilers and parsers. If you want separate types for the variants you end up writing repetitive shit like
this.
I'd like type annotations in some functions to be optional (and by optional i mean inferred, not some dynamic shit with unsound type systems). It can be done, the inference algo can handle most cases as evidenced by lambdas, but it's intentional because the types serve as documentation and they prevent you from accidentally changing the interface by changing the implementation. Neither should be an issue for private functions or when prototyping.
Type errors as warnings. This is a hard one because i am not 100% sure it can be done. I think
this comment describes a similar issue that my suggestion would run into though i haven't given it much thought. Basically the code would panic when you enter the wrongly typed path but only when you enter it. This would make refactoring easier since you wouldn't need to comment out huge blocks of code when changing types if you're unsure about your changes.
The newtype pattern is too verbose. When you realize Ada can express some things more
concisely (look for Types heading though the whole article is interesting) it makes you sad. Sometimes you wanna wrap a struct (or a few - the whole composition over inheritance thing) and forward some of its (their) methods. Currently you have to do it manually, i think Kotlin can do it using the `by` keyword but i can't find any good examples. Maybe it can't.
Similarly i'd like physical units as types. Xon had a bug because somebody was multiplying time by time instead of adding. That just shouldn't compile in 2019.
Some examples in The Book aren't the greatest - like associated types (can't find the bad example with graphs anymore, maybe it has been removed finally). Also i think it would benefit from a section about rust patterns - like using trait objects vs enums implementing traits - basically stuff you know how to do easily with inheritance (because pretty much all mainstream langs do it the same way) but rust has a slightly different pattern for it.
There's a couple more (implicit widening conversions, the whole "rust doesn't have inheritance so it sucks" thing, ...) but this is already getting long.