

Trickle: Spotify's library for composing asynchronous code in Java - jyrki
https://github.com/spotify/trickle

======
davedx
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...](https://github.com/excilys/androidannotations/wiki/WorkingWithThreads)

~~~
bkirwi
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.

~~~
mattgreenrocks
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?

~~~
bkirwi
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.

~~~
mattgreenrocks
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.

------
maaaats
This looks promising. The syntax is a bit clunky, however. How would this look
with Java8 and lambdas?

~~~
thescrewdriver
Probably a lot like [http://docs.scala-lang.org/sips/completed/futures-
promises.h...](http://docs.scala-lang.org/sips/completed/futures-
promises.html)

------
l3nz
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).

------
landakram
I'm curious — how does this deal with errors in async calls? RxJava has error
handling built in with `onError` functions.

~~~
pettermahlen
Trickle has a similar concept - you can add a 'fallback' to a node:
[https://github.com/spotify/trickle/blob/master/src/examples/...](https://github.com/spotify/trickle/blob/master/src/examples/java/com/spotify/trickle/example/Examples.java#L155)

------
foreigner
... or just use NodeJS instead.

~~~
mabufo
...to compose async code in Java?

