Ideas on further API change

There are several ideas I have on potential changes concerning current API, some of them are breaking changes:

1. Move away from returning effects. I still need to evaluate on that, but I think, it might be better to leave effect-free code in user hands. Requiring to return effect is pretty ugly in longer run, and it looks bad in terms of composition with user-defined code. Simple unit return may be enough.
2. Move away from AskResult<>: by default we should be able to interop with ask pattern just by using let! response = ref <? request and not having to unwrap the code each time if not necessary. If someone wants to have it presented in form of an object, he could use try pattern line let 'try block = try Success <| block() with e -> Failure e.
3. Since we expose actor context directly as function parameter, we might want to simply provide a mock for it in TestKit, that will record all method calls in form of list of events that we could use for assertions later. This way we could make unit tests on actors without need of creating a whole actor system, just passing context mock.
4. Look forward If we are able to fully integrate with async { ... } computation expression. The idea here is to be able to define actor not only from actor { ... } but directly from async look as well.

In general I’d like to reduce a footprint of Akkling API in user code in a way that user could potentially define his/her domain logic with minimal dependencies to Akka.NET/Akkling libraries.

[Horusiath]

@Neftedollar most of the API will remain intact, while things like Effects and AskResult will probably be simplified, this won’t be as noisy change as one would except in user code. I.e. while I want to get rid of Effect<>, user intent will still be possible to declare directly via returned behavior (see how akka-typed introduced behaviors).

Sample code:

let ref = spawn system "my-actor" <| props(fun ctx ->
    let rec loop () = actor {
        let! msg = m.Receive ()
        match msg with
        | "stop" -> return Stop
        | "unhandle" -> return Unhandled
        | x ->
            printfn "%s" x
            return! loop ()
    }
    loop ())

This looks exactly like existing code however, Stop and Unhandled won’t be instances of Effect<> interface any more, they will be behaviors (just like the loop function itself).

[Neftedollar]

I like 2nd, 3d and 4th points. I like your general idea. But what about effects? I understand that they are not following the idea of reducing API, but they are still very useful. Maybe they can be an optional extension library? (sorry if I’ve made mistakes in the text)