As a beginner, I think it's largely a matter of documentation.

In Go, you can very easily see all the methods that a type implements. However, you don't see which interfaces it implements because it's implicit.

In Rust, the methods are often hidden away in trait implementations, so it's harder to see what you can actually do.

It seems like this might be fixed if the doc tool generated an index to all the methods, as a reference? Or maybe there already is an easier way that I overlooked.

cargo doc does do that already, not sure what you mean.

IDEs should also be autocompleting trait impls.

My experience is that it will only autocomplete traits that you have imported. Which sucks because what if I don’t know what traits my type uses? It’s crazy

IntelliJ will suggest unimported trait methods and will automatically import the required trait if it is selected.

For example, on std:String, the + operator is hidden away in the Add trait implementation. (In this case it's reasonably obvious anyway.)

Ah, interesting. I haven't really noticed that sort of thing myself.

Async+Await+Futures isn't needed at all, performs worse than a basic epoll loop, is more confusing, and less able to handle complex flow. But they add a lot of complexity. The futures paragidm makes the hard stuff almost impossible to do efficiently.

It took c++ years to blow its complexity budge. Rust, "Hold my beer."

> Async+Await+Futures isn't needed at all

Define "needed" ? Code with async/await is radically simpler compared to without - this is not just basic sugar but really, really important due to rust's borrow semantics There is code I have written that required Rc/RefCell ceremony to get around the borrowchecker that will be completely handled by async/await.

You can read more about this here:

https://aturon.github.io/tech/2018/04/24/async-borrowing/

> performs worse than a basic epoll loop

There are open issues and afaik all of these are solvable problems with known/ theorized solutions.

> is more confusing, and less able to handle complex flow

Sorry, that's absolutely just not the case Even if "confusing" is subjective, you can not tell me that writing complex loops/ control flow is easier in futures than in async/await. Just look at the examples here:

https://docs.rs/dtolnay/0.0.4/dtolnay/macro._01__await_a_min...

There are programmers who mostly work on code that does a lot of work with the CPU, and needs to be multi core. For these applications, async/await has little to offer.

People who are puzzled by async/await often fall into this camp.

Why would they not just use threads?

Async and await solve a different problem to epoll (and do so in a cross-platform manner). A “basic epoll loop” won’t help you for file IO on Linux, for example.