Strongly typed code, please...

Dec 31, 2012 at 11:31 AM

What I like is strongly typed objects. Type-driven programming.

What I don't like is that even simple example has object[] parameters.

    public interface IActor
        object Eval(Func<IActorState, object[], object> function, object[] parameters);

Why can't we use generics? Could we transfer parameters with function? Or will there again be this <T1, T2, T3, T4, T5, T6, ..., TR> problem? Which states that C# is a wrong language for this kind of new modern programming solutions...


Jan 3, 2013 at 11:00 PM


Thanks for the input.  A couple of things in response:

  • I have encountered difficulty getting generics to work correctly in WCF interfaces.  :-(
  • In general, we would like our actors to be platform agnostic, which means that we will be making these public-facing interfaces even less strongly typed -- parameters will become JSON strings instead of .NET objects.  (In fact, if you look at the code instead of our slightly dated documentation, you can see that IActor.CallMethod already accepts JSON strings.)  Now, you can still enjoy a very strongly typed *client* for the actors, given a clever JSON [de]serializer (we use Json.NET and like it a lot), and we are trying to do that with our FabricActorClient .NET client.  But our ambition for the actor itself is to make it as platform- and type-ignorant as possible.

Obviously, we do rely on the ability to ship .NET assemblies to an actor in order to give it its "smarts", which kind of goes against the whole idea of platform agnosticism.  So the more properly stated ambition is "maintainable via .NET, consumable by any platform".





Feb 14, 2013 at 5:20 PM
I fully agree with Thorium on this subject, because maintaining a complex project with lot of different actors communicating with each other where everything is passed as object would be complete hell.

For example you could define communication contract with an actor as some typed C# interface in separate dll and then used code generation(t4 for example) to generate actual serialization and dispatching code specifically for each unique platform (C#, C++, Java etc). In this case you will still have full convenience of .Net to write actor code but would be able to consume it from any platform you want(just write another code gen backend).

I am writing this as I am working on quite similar actor framework for .Net in my spare time and I am quite keen on seeing strong and convenient actor framework arise for .Net world that would deal with actor coordination, ordered group broadcasts for same actor type, automatic segmentation of actors by some key-space, retrying and idempotency etc....
Feb 26, 2013 at 5:57 PM
Hi Rurouni,

Thanks for the feedback.

Our goal is to provide a non-prescriptive, highly available framework for developing actors. That "non-prescriptive" requirement means that we would like our actors (specifically, their methods) to be consumable from other platforms (Javascript, LUA, Ruby, etc...).

Accordingly, we are storing/transporting our actor data in what we deem to be the most portable format possible, that being JSON strings/objects. That seems to be a fairly universally understood format. The client can then use a clever JSON [de]serializer to convert those JSON strings/objects into strongly typed objects. Our FabricActorClient.CallMethod<T>() method calls an actor method and then deserializes the JSON return value into a T instance. FabricActorClient.CloudList<T> builds on this and is strongly typed. I'm fairly confident that clever JSON [de]serializers are written for other languages/platforms as well. To add support for a new platform, you just need to do the work once to integrate a clever JSON serializer into the method calling logic on the client for that platform, and then you can build more complicated, strongly typed client mechanisms on top of that.

I'm not sure that using some sort of C#/t4 typing scheme would be as simple or as universally understood as just storing/transmitting data in JSON format.

Now there may be problems here around the versioning of data types. Our framework won't automatically solve that problem for you, but it is possible to embed data type version numbers in your data and build your own versioning logic.

We've toyed with the idea of being able to assign a JSON Schema to an actor, so that all JSON data stored in that actor would have to conform to the assigned JSON schema. This would enable a reasonable facsimile of strong typing at the server level.

Hope that addresses some of your concerns,

P.S. You might have noticed that we still cheat and embed .NET type information into the JSON data that we store on actors. We plan on removing this .NET type information soon, so that we will truly just be storing portable JSON objects in our actors.
Feb 27, 2013 at 11:15 AM
Hi joehoag

While I can understand idea of being opened to all popular languages, I think that in reality : a guy who loves Ruby wouldn't use C# framework for actors on server, Javascript fan would use Node.JS and same goes for Python and especially Java(as they have Akka); and even if we talk about ASP.Net projects then only frontend nodes(written in C#) would be the ones that communicate with actors and not javascript in clients browser itself. So most of consumers of this framework would be C# enthusiasts in Server-Server scenarios and they will have degraded on the empty spot performance and increased bandwidth cost because of JSON, not even mentioning that they would either cast all the time from object or write their own typing/serialization scheme on top of this.

I agree that REST/JSON is great way of opening API to external parties, I just think that main usage of this framework would be for building internal infrastructure so we talking about finite set of teams cooperatively working in same environment and best approach in such case is just share contract dll's via internal NuGet repository. Even in case of multilingual environment there is reason why Google and Facebook are using things like protobuff or thrift internally.
Feb 27, 2013 at 4:39 PM

While we are indeed using C# to code our ActorFx infrastructure, I wouldn't call ActorFx a "C# framework for actors". As stated, our goal is to be non-prescriptive, allowing actor consumers to be written in many languages/platforms.

If we provide a Ruby client for actors, you don't think that Ruby folks would be intrigued? If we wrote a java client for actors and ported CloudList<T> to java, you don't think that it might pique the interest of java folks? From the client point of view, what we are building is simply a service with a JSON object store.

And our ultimate goal is not only to allow an actor service to be consumed by multiple platforms, but to allow actor methods to be defined in other languages. (This contradicts my earlier statement of "maintainable by .NET"; we would like to be maintainable by multiple platforms.) We are already examining the possibility of allowing actor methods to be defined in javascript and LUA, and I think that that possibility will materialize over the coming months. (Though, with two developers on the team, sometimes things don't happen as fast as we would like!)

I hope that that clears things up.

Feb 27, 2013 at 6:00 PM
Thank you Joe for your replies. In perspective of your plans it makes sense. I could argue that Javascript in general and JSON as serialization format are currently overhyped and not the best choice for high-performant server, but that would be just another holywar static vs dynamic typing, so I'll better wish you great success and popularity for this framework and will stay with cozy typed C# for myself :)
Feb 27, 2013 at 9:18 PM
Thanks Rurouni, always nice to hear other perspectives.

And with ActorFx you CAN live in a cozy typed C# world ... on the C# client. But, sure, I understand that trafficking in pure JSON data may not be everyone's cup of tea.

May 21, 2013 at 4:46 PM
i think in actual fact the AKKA, which is written in Scala, which is heavily biased towards typing, functional programming etc, advocate non typed actors.
Sep 5, 2013 at 6:26 AM
joehoag wrote:
If we provide a Ruby client for actors, you don't think that Ruby folks would be intrigued?
Ruby has celluloid, which is a very Ruby-styled actor model and currently use in many active projects. Further, Microsoft abandoned IronRuby, further alienating that community. I don't think they have any idea that ActorFx exists, nor would I expect them to care (, good as it may be.)
If we wrote a java client for actors and ported CloudList<T> to java, you don't think that it might pique the interest of java folks?
Akka has become something of a gold standard, for better or worse. I would be very surprised to see a lot of momentum towards this over Akka unless you are able to compete head-to-head with Erlang in terms of performance and SLA.
From the client point of view, what we are building is simply a service with a JSON object store.
If that's the case, how is this really different from a service bus?