3 ms·

Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...

by RyanZAG 13y ago

lmm 13y ago
Java's future API is inadequate - you can only block on a future or poll it, not ask to be notified when it completes, so you end up needing a thread for each future which loses a lot of the benefits. I haven't used Qasar specifically but I did use other java extensions that add some scala features for a while (Lombok and the Checkers Framework). The thing is, once you're using those you're effectively using a different language ("extended java") with its own bugs - and the community for that language is much smaller than that for scala.
- justinsb 13y ago
  It is a weird omission, not least because it seems that anyone that wants to use Futures ends up extending it in the same (but incompatible) way. Guava has ListenableFuture, Netty has its own version, etc. I'm not sure how this happened, but I just use Guava's ListenableFuture and am happy again.
  - RyanZAG 13y ago
    It was omitted because it's a complex design issue. Someone using the future would assume that if they added a callback, it would run on the same thread that they called it from. That's not possible in the general case: the thread they called it on may not have an event loop and so could not be directly notified. It's better to leave this to frameworks or libraries that have their own event loop mechanism to handle callbacks.
- laureny 13y ago
  > not ask to be notified when it completes This is trivial to add (Guava offers it as ListenableFuture), but either way, it's a library concern, not a language one, so I don't think it makes sense to pit Java and Scala over this.
  - lmm 13y ago
    The standard library matters, particularly because Java doesn't let you smooth over these incompatibilities with implicits. But you're right, I should've said that the syntax (while a vast improvement over previous Java) is not as nice as for/yield, and the lack of higher-kinded types in Java means you can't write functions that handle Futures and other types with similar semantics generically.

Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...

by RyanZAG 13y ago

Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...

lmm 13y ago

Java's future API is inadequate - you can only block on a future or poll it, not ask to be notified when it completes, so you end up needing a thread for each future which loses a lot of the benefits. I haven't used Qasar specifically but I did use other java extensions that add some scala features for a while (Lombok and the Checkers Framework). The thing is, once you're using those you're effectively using a different language ("extended java") with its own bugs - and the community for that language is much smaller than that for scala.

justinsb 13y ago
It is a weird omission, not least because it seems that anyone that wants to use Futures ends up extending it in the same (but incompatible) way. Guava has ListenableFuture, Netty has its own version, etc. I'm not sure how this happened, but I just use Guava's ListenableFuture and am happy again.
- RyanZAG 13y ago
  It was omitted because it's a complex design issue. Someone using the future would assume that if they added a callback, it would run on the same thread that they called it from. That's not possible in the general case: the thread they called it on may not have an event loop and so could not be directly notified. It's better to leave this to frameworks or libraries that have their own event loop mechanism to handle callbacks.
laureny 13y ago
> not ask to be notified when it completes This is trivial to add (Guava offers it as ListenableFuture), but either way, it's a library concern, not a language one, so I don't think it makes sense to pit Java and Scala over this.
- lmm 13y ago
  The standard library matters, particularly because Java doesn't let you smooth over these incompatibilities with implicits. But you're right, I should've said that the syntax (while a vast improvement over previous Java) is not as nice as for/yield, and the lack of higher-kinded types in Java means you can't write functions that handle Futures and other types with similar semantics generically.