Trickle: Spotify's library for composing asynchronous code in Java(github.com)
github.com
Trickle: Spotify's library for composing asynchronous code in Java
https://github.com/spotify/trickle
6 comments
Interesting idea, but my eyes bleed. And I'm a Java programmer. Would rather use Akka or SlicedBread (the latter trading almost all features for the added simplicity but working well and being super-simple).
I'm curious — how does this deal with errors in async calls? RxJava has error handling built in with `onError` functions.
Trickle has a similar concept - you can add a 'fallback' to a node: https://github.com/spotify/trickle/blob/master/src/examples/...
This looks promising. The syntax is a bit clunky, however. How would this look with Java8 and lambdas?
Probably a lot like http://docs.scala-lang.org/sips/completed/futures-promises.h...
Agreed, it looks super clunky. Even JS feels clunky for me at times for async stuff, compared to, say CoffeeScript. But I suppose it's possibly the case that async isn't used as much in Java, compared to its ubiquity in the browser.
sexy
I much prefer the Android Annotations [1] approach to asynchronous functions, but I'm not sure they are solving exactly the same problem. Can anyone comment?
[1] https://github.com/excilys/androidannotations/wiki/WorkingWi...
[1] https://github.com/excilys/androidannotations/wiki/WorkingWi...
I can comment!
I'm not very familiar with Android Annotations, but they seem to be primarily a way to shuffle some processing to a background thread. All those methods return `void`, so if that method wants to return some results (or failures) to the caller, it needs to find some other mechanism to do so. It's not impossible, but it's bound to be more inconvenient than a plain old return value.
A common solution is to return what Trickle calls a `ListenableFuture`. The method can do any amount of async processing (on a background thread, or using async I/O, or whatever) and eventually will 'populate' that future with a value. You can test if that value has been set at any time, or add a callback to be called when the future completes / fails.
The problem with that solution comes when you're dealing with multiple APIs, and need the results of some as inputs to others. (This is commonly known as 'callback hell'.) Trickle's solution to this is to make you define the information-flow graph explicitly, and it does all the shuttling-of-intermediate-results around for you. It seems like an improvement, but I much prefer the RxJava / Akka approach to this, since the types are checked and error handling is more explicit and convenient.
I'm not very familiar with Android Annotations, but they seem to be primarily a way to shuffle some processing to a background thread. All those methods return `void`, so if that method wants to return some results (or failures) to the caller, it needs to find some other mechanism to do so. It's not impossible, but it's bound to be more inconvenient than a plain old return value.
A common solution is to return what Trickle calls a `ListenableFuture`. The method can do any amount of async processing (on a background thread, or using async I/O, or whatever) and eventually will 'populate' that future with a value. You can test if that value has been set at any time, or add a callback to be called when the future completes / fails.
The problem with that solution comes when you're dealing with multiple APIs, and need the results of some as inputs to others. (This is commonly known as 'callback hell'.) Trickle's solution to this is to make you define the information-flow graph explicitly, and it does all the shuttling-of-intermediate-results around for you. It seems like an improvement, but I much prefer the RxJava / Akka approach to this, since the types are checked and error handling is more explicit and convenient.
Nice write-up.
I'm surprised people don't mind chaining together the information flow like this; it feels more like the runtime should do this sort of leg work. I understand why you'd do this on servers, but not as much on clients. Why not tie up a worker thread waiting for these things?
I'm surprised people don't mind chaining together the information flow like this; it feels more like the runtime should do this sort of leg work. I understand why you'd do this on servers, but not as much on clients. Why not tie up a worker thread waiting for these things?
I agree, you're unlikely to feel the need for this when threads are cheap and blocking is OK. (For some client environments, like JavaScript, that's not the case: which is why you see so many similar things in that space, like promises and bacon.js.)
Though in some languages the syntax is light enough that it's actually more convenient to do in in the nonblocking style; Scala has a good story here, and C#'s async/await seems perhaps even cleaner.
Though in some languages the syntax is light enough that it's actually more convenient to do in in the nonblocking style; Scala has a good story here, and C#'s async/await seems perhaps even cleaner.
That's what pains me about JS: there's this meme of being unable to use threads, but it's OK, because threads are bad and scary. Thus, promises must be good.
Async/await is beautiful: compiler produces CPS, but logical control flow remains exactly as you'd expect. One slight reservation: the async specifier seems to pollute the entire call tree of otherwise un-related code.
Async/await is beautiful: compiler produces CPS, but logical control flow remains exactly as you'd expect. One slight reservation: the async specifier seems to pollute the entire call tree of otherwise un-related code.
I think they address different use-cases.
AA is for simple UI related asynchronous calls.
While this lib is for complicated nested asynchronous calls. On Android a good example would be in app purchases. To consume an IAP there's an async call to connect to Google Play, followed by an async call to query inventory, followed by an async call to consume the item. It gets hairy fast!
AA is for simple UI related asynchronous calls.
While this lib is for complicated nested asynchronous calls. On Android a good example would be in app purchases. To consume an IAP there's an async call to connect to Google Play, followed by an async call to query inventory, followed by an async call to consume the item. It gets hairy fast!
[deleted]