Future, akka-stream, scalaz-stream

Lgd. Viktor Klang @viktorklang

@djspiewak Re-running it I have not attempted. That sounds like it will become tricky. My point still stands tho, re "running computation".

Daniel Spiewak @djspiewak

@viktorklang Well, if I could rephrase and qualify your point, it is that Future represents a computation who’s state is dependent on the EC

Lgd. Viktor Klang @viktorklang

@djspiewak Or simply: A Future represents a value -in the future-.

Lgd. Viktor Klang @viktorklang

@djspiewak Don't confuse it. Future.successful(something) is not a computation. val f = Promise[T]().future is not a computation.

Daniel Spiewak @djspiewak

@viktorklang Ok, well I think it’s fair to say that a lot of people are using it as a model to control computation, perhaps not realizing

Daniel Spiewak @djspiewak

@viktorklang So that’s the source of the misconception.

Lgd. Viktor Klang @viktorklang

@djspiewak Computation is what links Futures to Futures—think map, flatMap, filter, whathaveyou. Just wanted to clear up the confusion.

Lgd. Viktor Klang @viktorklang

@djspiewak On another topic, I think it's very interesting with lifted representations of transformation, there are tons of possibilities…

Daniel Spiewak @djspiewak

@viktorklang @jessitron I’m pretty sure I could properly type the step function using Shapeless. It’s definitely crazy though. Easy in Idris

Daniel Spiewak @djspiewak

@viktorklang @jessitron The problem is that the step function represents an arbitrary transition in a state machine, and he wants that typed

Daniel Spiewak @djspiewak

@deanwampler @viktorklang @jessitron You would actually need full dependent types.

Daniel Spiewak @djspiewak

@jessitron @viktorklang Actually, as @d6 pointed out to me, we did something very similar at Precog, and it was strongly typed.

Daniel Spiewak @djspiewak

@jessitron @viktorklang So it’s not so much that the types would inhibit the idea. It’s more that types would inhibit Rich’s version.

Lgd. Viktor Klang @viktorklang

@djspiewak Noooo, Akka streams is not a push model :( *cries on teh insidez* youtube.com/watch?feature=… It's a bounded dynamic push-pull.

Daniel Spiewak @djspiewak

@viktorklang For the purposes of what I was describing, it’s mostly push. But yes, I’ve already been corrected on that one. :-)

Daniel Spiewak @djspiewak

@viktorklang I believe I did give the disclaimer that I am very new to the space and know very little about the other options.

Lgd. Viktor Klang @viktorklang

@djspiewak No worries. The fun thing with Akka Streams is that it automatically switches between push and pull depending on who is slower.

Daniel Spiewak @djspiewak

@viktorklang Yeah, I think RxJava does the same. I prefer pure pull, but there’s no question that it doesn’t work as well for some things.

Lgd. Viktor Klang @viktorklang

@djspiewak RxJava is doing the same (see reactive-streams.org), pull-based is bounded but allows for nothing but lock-step==inefficient.:(

Daniel Spiewak @djspiewak

@viktorklang Look more closely at scalaz-stream. It’s not just lock step. :-)

Daniel Spiewak @djspiewak

@viktorklang In fairness, when you use the scalaz-stream tools that allow racing and such, it does push-like things underneath.

Lgd. Viktor Klang @viktorklang

@djspiewak Any particular pointers/links to see that? :)

Daniel Spiewak @djspiewak

@viktorklang The general combinator is wye. One of the more useful variants is merge.mergeN. I talk about them in my presentation.

Lgd. Viktor Klang @viktorklang

@djspiewak Btw, have you seen this deck? ecoop14.it.uu.se/programme/DrSt…

Lgd. Viktor Klang @viktorklang

@djspiewak I'm watching your talk as we speak. :)