Thomas Nield

Correction: It looks like ReactFX has [threadBridge](http://www.reactfx.org/javadoc/stable/org/reactfx/EventStream.html#threadBridge-java.util.concurrent.Executor-java.util.concurrent.Executor-) so I stand corrected on my concurrency comments. But RxJava support would still be nice especially for those of us who do not...

@orangy will do : )

Hey has anyone looked at [TornadoFX](https://github.com/edvin/tornadofx)? It looks like it has Kotlin builders too?

I'll at least start this and put in a PR.

Here are some proposed extensions we can start with: ```kotlin fun Iterable.toMatrix(vararg valueSelectors: (T) -> Double): Matrix { val list = toList() val out = zeros(rows=list.size, cols= valueSelectors.size) for ((m,t)...

I think you mentioned we should support different matrix types beyond `Double` since those can be supported in the backend? We might name them `toDoubleMatrix()` as well as `toMatrix()` for...

Do we even manually invoke these functional types that often? I'm struggling to see practical use cases here. Also, I don't see value in those toAction() extensions since SAM handling...

Yes, this is a discussion we recently started having on the #rx channel in Kotlin Slack. While we initially thought it would be impractical to do a pure Kotlin implementation...

@stepango @JakeWharton also lightweight in that a coroutine-backed RxKotlin would use fibers instead of threads. Coroutines naturally handle backpressure so we would not have any overhead for that as well.

I agree, regardless there will at least be an easier to use, more maintainable Rx implementation in pure Kotlin. I'm kind of busy for the next week or two with...