[Concurrency] Reactive streams as building blocks for actors etc.

Many of the currently popular server side frameworks are switching to
Reactive Streams:

    http://en.wikipedia.org/wiki/Reactive_Streams#Adoption

for their underlying communication, including Akka. Reactive Streams are
also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and
built its Actor implementation etc. on top of this protocol?

  -- Howard.

More info on Reactive streams:

https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1/README.md#specification

    http://bryangilbert.com/post/code/scala/akka-reactive-streams/

Many of the currently popular server side frameworks are switching to Reactive Streams:

    http://en.wikipedia.org/wiki/Reactive_Streams#Adoption

for their underlying communication, including Akka. Reactive Streams are also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and built its Actor implementation etc. on top of this protocol?

In MHO, yes, it would be great to build a reactive stream abstraction as well. I agree with you that this is an effectively “obvious” part of the eventual model, and that we will almost certainly end up building it. It would also make sense to have foreach over an async sequence be itself implicitly async. I haven’t sketched that out, but it seems like a few straight-forward steps beyond what is in the manifesto doc.

I’ve added a mention of these to the doc, thanks!
https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#further-extensions

-Chris

···

On Aug 28, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

  -- Howard.

More info on Reactive streams:

    https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1/README.md#specification

    http://bryangilbert.com/post/code/scala/akka-reactive-streams/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think this is what you mean by parallel forEach, I have just expanded the
wording below to be clearer (for myself primarily).

The Java equivalent of a `LazySequenceProtocol` has a parallel method that
returns a parallel lazy sequence, so that operations like map, reduce,
filter, and forEach all run in parallel. I have used this a lot to speed up
code and it would be another great addition.

  -- Howard.

···

On 29 August 2017 at 16:14, Chris Lattner <clattner@nondot.org> wrote:

On Aug 28, 2017, at 6:56 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote:

Many of the currently popular server side frameworks are switching to
Reactive Streams:

    http://en.wikipedia.org/wiki/Reactive_Streams#Adoption

for their underlying communication, including Akka. Reactive Streams are
also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and
built its Actor implementation etc. on top of this protocol?

In MHO, yes, it would be great to build a reactive stream abstraction as
well. I agree with you that this is an effectively “obvious” part of the
eventual model, and that we will almost certainly end up building it. It
would also make sense to have foreach over an async sequence be itself
implicitly async. I haven’t sketched that out, but it seems like a few
straight-forward steps beyond what is in the manifesto doc.

I’ve added a mention of these to the doc, thanks!
https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f7
82#further-extensions

-Chris

  -- Howard.

More info on Reactive streams:

    https://github.com/reactive-streams/reactive-streams-jvm/
blob/v1.0.1/README.md#specification

    http://bryangilbert.com/post/code/scala/akka-reactive-streams/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

That would be definitely a great addition to the language. IMO, Dart gets this right:

https://www.dartlang.org/tutorials/language/futures
https://www.dartlang.org/tutorials/language/streams

In general, I would prefer an async story like this:

- support coroutines / generators (yield)
- use coroutines to implement Future and Stream/Observable
- optionally provide async/await as syntax sugar for Future/Stream (or just reuse yield)

-g.

···

On 29 Aug 2017, at 4:56 AM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

Many of the currently popular server side frameworks are switching to Reactive Streams:

    http://en.wikipedia.org/wiki/Reactive_Streams#Adoption

for their underlying communication, including Akka. Reactive Streams are also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and built its Actor implementation etc. on top of this protocol?

  -- Howard.

More info on Reactive streams:

    https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1/README.md#specification

    http://bryangilbert.com/post/code/scala/akka-reactive-streams/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I have put on Github three concurrency libraries (
https://github.com/hlovatt/Concurrency-Utilities):

  1. Atomic - with `get`, `set`, and `update` methods
  2. Future - with `get`, `cancel`, and `status` methods
  3. Reactive Streams - with protocols `Processor`, `Producer`,
`Subscriber`, and `Subscription`, with implementations of `ForEachProducer`
and `ReduceSubscriber`, and with operator `~>` for subscriptions

For those not familiar, Reactive Streams are a standardised form of a type
of actor that have become popular and are available in multiple languages.

Here is Hello World in the Reactive Stream library:

    let helloWorldPublisher = ForEachPublisher(sequence: "Hello,
world!".characters)
    let helloWorldSubscriber = ReduceSubscriber(into: "") { (result: inout
String, next: Character) in
        result.append(next) // Copy the string a character at a time.
    }
    helloWorldPublisher ~> helloWorldSubscriber // Subscribe
    let helloWorldResult = helloWorldSubscriber.get ?? "Failed!" // Wait
for result and check for error

Note how the arguments to `ForEachProducer` and `ReduceSubscriber` mimic
those to similarly named methods in Swifts `Sequence` protocol, how `~>` is
evocative of the process that is occurring, and how future's `get` controls
execution and error reporting.

If anyone experiments with them and provide feedback :), it would be
greatly appreciated.

Thanks,

-- Howard.

  -- Howard.

···

On 3 September 2017 at 17:36, Georgios Moschovitis < george.moschovitis@icloud.com> wrote:

That would be definitely a great addition to the language. IMO, Dart gets
this right:

https://www.dartlang.org/tutorials/language/futures
https://www.dartlang.org/tutorials/language/streams

In general, I would prefer an async story like this:

- support coroutines / generators (yield)
- use coroutines to implement Future and Stream/Observable
- optionally provide async/await as syntax sugar for Future/Stream (or
just reuse yield)

-g.

On 29 Aug 2017, at 4:56 AM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote:

Many of the currently popular server side frameworks are switching to
Reactive Streams:

    http://en.wikipedia.org/wiki/Reactive_Streams#Adoption

for their underlying communication, including Akka. Reactive Streams are
also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and
built its Actor implementation etc. on top of this protocol?

  -- Howard.

More info on Reactive streams:

    https://github.com/reactive-streams/reactive-streams-jvm/
blob/v1.0.1/README.md#specification

    http://bryangilbert.com/post/code/scala/akka-reactive-streams/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution