-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Future.get #9
Comments
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? |
So you're stating that a design choice should be based in an implementation detail? |
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. |
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. |
@huntc Thanks for the feedback and sorry for the late response. You are probably right now that rust switched to native threads a public |
👍 |
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.
The text was updated successfully, but these errors were encountered: