3 ms·

None of what you're describing really tracks for me, having written many thousands of lines of rust and interfacing with my third party crates. "async/await do

None of what you're describing really tracks for me, having written many thousands of lines of rust and interfacing with my third party crates. "async/await doesn't solve much" like your whole post confuses me. I think right now a lot of rust libraries are "hyper generic" because they're intended to be lower level and to be built on top of. Like hyper, as an example. I've never found it particularly hard to work with generic libraries though.

jnordwick 7y ago
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."
- staticassertion 7y ago
  > 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/ 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_minute.html https://docs.rs/dtolnay/0.0.4/dtolnay/macro._01__await_a_min...
  - woah 7y ago
    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.
    - staticassertion 7y ago
      Why would they not just use threads?
- jen20 7y ago
  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.
skybrian 7y ago
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.
- staticassertion 7y ago
  cargo doc does do that already, not sure what you mean. IDEs should also be autocompleting trait impls.
  - skybrian 7y ago
    For example, on std:String, the + operator is hidden away in the Add trait implementation. (In this case it's reasonably obvious anyway.)
    - staticassertion 7y ago
      Ah, interesting. I haven't really noticed that sort of thing myself.
  - rhodysurf 7y ago
    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
    - rakenodiax 7y ago
      IntelliJ will suggest unimported trait methods and will automatically import the required trait if it is selected.

jnordwick 7y ago

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."

staticassertion 7y ago
> 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/ 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_minute.html https://docs.rs/dtolnay/0.0.4/dtolnay/macro._01__await_a_min...
- woah 7y ago
  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.
  - staticassertion 7y ago
    Why would they not just use threads?
jen20 7y ago
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.

skybrian 7y ago

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.

staticassertion 7y ago
cargo doc does do that already, not sure what you mean. IDEs should also be autocompleting trait impls.
- skybrian 7y ago
  For example, on std:String, the + operator is hidden away in the Add trait implementation. (In this case it's reasonably obvious anyway.)
  - staticassertion 7y ago
    Ah, interesting. I haven't really noticed that sort of thing myself.
- rhodysurf 7y ago
  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
  - rakenodiax 7y ago
    IntelliJ will suggest unimported trait methods and will automatically import the required trait if it is selected.