Remove Future.get

[huntc]

Future should not offer a get method. If it does then it will be abused. Trust me. :-)

on_success can probably be replaced with for_each. Scala will likely deprecate onSuccess in its Future api.

[matiwinnetou]

Actually i am not so sure, blocking threads is expensive in java but for example in google go it is not expensive. It really depends how rust implements ITS threading model. But even in Java Have you seen Fibers project by pararrel universe?

[huntc]

So you're stating that a design choice should be based in an implementation detail?

[matiwinnetou]

IMHO, yes because the implementation could mean that this abstraction may or may not be necessary. Abstraction is always for something. In case of Scala futures and promises and overall async api make total sense - since blocking threads on JVM is costly in case of Google Go or Rustlang, Fibers the "implementation detail" may not justify the necessity for this abstraction. One exception for me would be composability and ability to interleave streams (means they don't block) as in case of Iteratees but one has to find those use cases since blocking threads is expensive in Java but may not be on other platforms.

[huntc]

It really depends how rust implements ITS threading model.

I'm basing this request entirely in the doc generally available and therefore Rust's current approach. It appears that threads are used, at least at this point. I've not studied this repo's implementation to see whether it depends on fibers or not.

In summary, if threads are used, get rid of get. It will be abused otherwise.

[lucidd]

@huntc Thanks for the feedback and sorry for the late response. You are probably right now that rust switched to native threads a public get method is a bad idea. I will probably remove it in the future.

[viktorklang]

:+1: