confusion specific to Java

[nikomatsakis]

Brief summary

Alan is accustomed to implementing services in Java He has design patterns in his mind that don't work in Rust. He also gets confused by specific things around async Rust / Rust futures. What are they?

Optional details

• (Optional) Which character(s) would be the best fit and why?
  • [x] Alan: the experienced "GC'd language" developer, new to Rust
  • [ ] Grace: the systems programming expert, new to Rust
  • [ ] Niklaus: new programmer from an unconventional background
  • [ ] Barbara: the experienced Rust developer

[nikomatsakis]

Example I've heard: In Java, a Future represents a value executing in another thread. Futures in Rust do not necessarily represent that.

[urhein]

Not sure how much this helps, but this is already a misconception in Java: Futures don't necessarily execute on a different thread (although that may be the most common case), and they may not even strictly have an execution attached to them (e.g. the CompletableFuture).

Just conceptually, Java's ("A Future represents the result of an asynchronous computation") and Rust's ("A future represents an asynchronous computation") definitions are pretty similar. What confused me the most were the differences in behavior:

• Futures in Rust don't do anything on their own: It's the caller's responsibility to "drive them to completion" (by awaiting or other methods). In Java, the class that hands you the Future will (almost always) do this for you.
• You're not going to use Future::poll as I'm using Future.get() in Java.
• In Java, I can call Future.get() as many times as I want, and in as many threads as I want.
• Futures in Java can be explicitly cancelled (compared to the cancel-on-Drop behavior in Rust)

[nikomatsakis]

@urhein I was talking to some folks and we realized that Rust's Future is really more analogous to Java's Callable.