Topics

[richorama]

Thread to discuss topics you would like to cover. Please also suggest talks you would like to give.

[ReubenBond]

Very interesting, @yevhen. You lose compile-time type safety, though - doesn't that bother you? What about deriving your grain contract from multiple IEventHandler<TEvent> interfaces - one for each event - instead of using object and dynamic. You get to keep type safety and don't suffer the runtime penalty of dynamic (https://stackoverflow.com/questions/13193799/performance-cost-of-using-dynamic-typing-in-net).

[yevhen]

@ReubenBond

You lose compile-time type safety, though - doesn't that bother you?

Not at all. I do exhaustive unit testing :) Even if you don't - it wasn't such a big problem before.

Akka.Net does a similar thing with its TypedActor base class and IHandles<T> interface. But it's only for invocation side. The point here was that there is no need to create a dedicated grain contract interface, since the set of messages (along with exceptions) which grain could process/raise, fully defines it's public interface (contract).

[johnazariah]

hahah - I think Yehven meant to say "Yes, I do lose compile-time type safety, but I cover for it with unit testing" :)

I raised this as a comment as well - and I think Yehven agreed that the F# DU model has stronger compile-time guarantees :)

On Sat, Mar 7, 2015 at 9:13 AM, Yevhen Bobrov notifications@github.com wrote:

@ReubenBond https://github.com/ReubenBond

You lose compile-time type safety, though - doesn't that bother you?

Not at all. I do exhaustive unit testing :) Even if you don't - it wasn't such a big problem before.

Akka does a similar thing with its TypedActor base class and `IHandles' interface. But it's only for invocation side. The point here was that there is no need to create a dedicated grain contract interface, since the set of messages (along with exceptions) which grain could process/raise, fully defines it's public interface (contract).

— Reply to this email directly or view it on GitHub https://github.com/OrleansContrib/meetups/issues/1#issuecomment-77646030 .

• John

John Azariah | Microsoft Azure MVP https://mvp.microsoft.com/en-us/mvp/John%20Azariah-5000463

m +61 421 100 747 e john.azariah@gmail.com t @johnazariah http://twitter.com/johnazariah

[yevhen]

@ReubenBond

You get to keep type safety and don't suffer the runtime penalty of dynamic (https://stackoverflow.com/questions/13193799/performance-cost-of-using-dynamic-typing-in-net)

That was just an example. Something simple. just to showcase the concept. In fact, I don't use dynamic much but rather complied lambda expressions, which is pretty close to a direct method call.

Also, the information in this SO post is outdated. dynamic was highly optimized in recent versions of .NET framework (same as Activator.CreateInstance) so it's usually only slow on a first call and then all further invocations are incredibly fast.

[yevhen]

@johnazariah

hahah - I think Yehven meant to say "Yes, I do lose compile-time type safety, but I cover for it with unit testing" :)

Indeed :)

[ReubenBond]

That's fair enough, Yehven. I guess I like the discoverability which static typing gives me, letting me autocomplete my way around.

[yevhen]

@ReubenBond

I guess I like the discoverability which static typing gives me, letting me autocomplete my way around

Is that the only thing that might stop you from trying this approach (message passing). Compared to all other advantages that you might get when using it? :)

How many messages per actor type you now have, so that the absence of auto-discoverability is a real issue?

[yevhen]

Also, I can show you the trick how to make auto-discoverability possible with message passing. It requires creating an additional extension method for uniform interface and some trivial inheritance modeling skills :)

It's basically just a way to represent DUs in C# ...

[yevhen]

@johnazariah

I raised this as a comment as well - and I think Yehven agreed that the F# DU model has stronger compile-time guarantees :)

Yes, this approach (message passing) looks really sleek in F#. Example from my PoC https://github.com/yevhen/Orleankka/blob/master/Source/FSharp.Demo/Shop.fs

That should change with C#7 when record types and pattern matching will be introduced

[ReubenBond]

I've used this approach before (in Akka & in one of my early Orleans projects). Message passing is great, but I prefer explicit contracts - Orleans uses message passing under the hood, anyway.

If I were to go down this route, I would likely use this approach:

public interface IMyGrain : IGrain, IHandleEvent<EventOne>, IHandleEvent<EventTwo>{}

Where IHandleEvent is just

public interface IHandleEvent<T>
{
    Task Handle(T @event);
}

[yevhen]

@ReubenBond Yes, unfortunately it's not quite the same. That will make an interface non-uniform and you will lose a higher-order function, through which each and every message will be delivered to a grain. And it is the most important thing here.

But if you don't need the power that such a higher-order receive function could give, then even the current Orleans' method-based approach will be fine.

[yevhen]

And all of this is problematic only due to C# FP immaturity. With F# - message passing is superior :)

[ReubenBond]

Why would you lose the ability to use higher-order functions? Instead of object, my functions operate on TEvent. Do you have an example? I'm not saying C#'s type system is particularly robust, but it's robust enough for most cases.

[yevhen]

Because Orleans will dispatch TEvent directly to a concrete handler, the one that has Handle(TEvent e) signature, and not to the Handle(object e) catch-all function.

[johnazariah]

Hey I'm loving what I'm seeing of Orleankka! Can I start using it? :D

[yevhen]

@johnazariah sure :) I'll be updating Nuget package next week with recent developments. It should be completely on-par with all of the features of native Orelans API.

What is missing is:

1. Automatic deactivation timeouts on per actor-type basis (1 hour of work even for newbie, with uniform interface approach)
2. Fluent configuration for Azure - if you've seen what we did there with simplified configuration DSL, then you know what I'm talking about :)
3. Bring back support for Orleans' native serialization - 5 lines of code, literally ...

Thanks for compliment!

[yevhen]

@johnazariah But these polishing should not introduce any breaking changes. We might change signature of IActorActivator but that should be a single place change for clients, so nothing very serious here

[johnazariah]

Nice - i can't contribute right now, but in 2-3 months, I'll have some time, hopefully!

[yevhen]

@johnazariah cool! We're thinking about moving it to OrleansContrib.

[johnazariah]

OK - that sounds great!

[richorama]

Who is up for speaking at the next meetup? @gabikliot mentioned that he could talk about the streaming API, but @ReubenBond is also lined up for talking about how he's using Orleans at some point? Do you guys have any dates you could provide?

[gabikliot]

If @ReubenBond can do the next one, I think it will be preferred from our side. We will the do one after that and hopefully by that time we will be done with stream provider refactoring, so there will be more to talk about. But if Reuben can't, we can do the next one as well. How about meetup #4 in 3 weeks and meetup #4 a month later?

[ReubenBond]

I can do the next one, whenever you would like to schedule it, at least 2 weeks from now.

I'll talk about "How we use Orleans in FreeBay", if people are interested. I'll write up some slides and whatnot, but I'll cover AuthN/AuthZ, the admin console, the streaming API, and how the system is modeled.

If people have suggestions for things they would like me to cover, I will incorporate them.

[johnazariah]

+1 for the streaming API

On Thu, Mar 12, 2015 at 2:05 PM, Reuben Bond notifications@github.com wrote:

I can do the next one, whenever you would like to schedule it, at least 2 weeks from now.

I'll talk about "How we use Orleans in FreeBay", if people are interested. I'll write up some slides and whatnot, but I'll cover AuthN/AuthZ, the admin console, the streaming API, and how the system is modeled.

If people have suggestions for things they would like me to cover, I will incorporate them.

— Reply to this email directly or view it on GitHub https://github.com/OrleansContrib/meetups/issues/1#issuecomment-78416063 .

• John

John Azariah | Microsoft Azure MVP https://mvp.microsoft.com/en-us/mvp/John%20Azariah-5000463

m +61 421 100 747 e john.azariah@gmail.com t @johnazariah http://twitter.com/johnazariah

[richorama]

@ReubenBond how does Friday 10th April 19:00 UTC sound?

[ReubenBond]

Looks good to me. Lock it in :) thanks

-----Original Message----- From: "Richard Astbury" notifications@github.com Sent: ‎13/‎03/‎2015 02:27 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Reuben Bond" reuben.bond@gmail.com Subject: Re: [meetups] Topics (#1)

@ReubenBond how does Friday 10th April 19:00 UTC sound? — Reply to this email directly or view it on GitHub.

[ReubenBond]

Something has come up, could we please shift this by a couple of days? Any time in the week following is suitable for me.

[richorama]

No probs. Do you want to update the readme with a new date? I'm OOF at the moment...

-----Original Message----- From: "Reuben Bond" notifications@github.com Sent: ‎07/‎04/‎2015 11:16 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

Something has come up, could we please shift this by a couple of days? Any time in the week following is suitable for me. — Reply to this email directly or view it on GitHub.

[ReubenBond]

Updated to Tue, 15th April 2015, 19:00 - 20:00 GMT. Does that work? I don't have the rights to update the Google Hangout event, are you able to update that?

[richorama]

Hmm, I might struggle to make it (I think it's the only day that week which I'm out on the road). Although I'm not essential for being there!

[ReubenBond]

Let's bump it to Wednesday, then :) I've updated the README.

[richorama]

:-)

-----Original Message----- From: "Reuben Bond" notifications@github.com Sent: ‎08/‎04/‎2015 08:48 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

Let's bump it to Wednesday, then :) I've updated the README. — Reply to this email directly or view it on GitHub.

[richorama]

Link for the current meetup - starting minutes... https://plus.google.com/hangouts/_/hoaevent/AP36tYfV4VTQggg4M1DDYLy6ggGhwFvRyAj-tZA9gPrlZFl_Rlolew

[sergeybykov]

We don't have a date set up for next meetup where @gabikliot is going to dive into streaming, do we?

[richorama]

Not yet ;-) do you have have a date Gabi?

-----Original Message----- From: "Sergey Bykov" notifications@github.com Sent: ‎26/‎04/‎2015 21:39 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

We don't have a date set up for next meetup where @gabikliot is going to dive into streaming, do we? — Reply to this email directly or view it on GitHub.

[gabikliot]

How about 3 weeks from now, May 15th or May 22nd?

[javier-alvarez]

I'm interested and day should work for me

-----Original Message----- From: "Gabriel Kliot" notifications@github.com Sent: ‎28/‎04/‎2015 18:09 To: "OrleansContrib/meetups" meetups@noreply.github.com Subject: Re: [meetups] Topics (#1)

How about 3 weeks from now, May 15th or May 22nd? — Reply to this email directly or view it on GitHub.

[richorama]

@gabikliot either date is great.

It would be great if someone else could volunteer to host the meetup, there's a good chance I won't be able to join as I'm moving house (to a house with no internet at the moment) and having a baby (well my wife is - but I need to help apparently).

[sergeybykov]

@richorama Congratulations with the baby!

I've never hosted a Hangout, but if nobody more experienced steps in, I can try to play Richard this time.

[gabikliot]

Indeed, congratulations with the baby Richard! I think lets pick May 22nd? It will give us enough time to finish the stream providers refactoring we are working on now and present a more coherent story.

[richorama]

Brilliant, let's make it the 22nd, and if Sergey could host, that would be great!

-----Original Message----- From: "Gabriel Kliot" notifications@github.com Sent: ‎01/‎05/‎2015 19:57 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

Indeed, congratulations with the baby Richard! I think lets pick May 22nd? It will give us enough time to finish the stream providers refactoring we are working on now and present a more coherent story. — Reply to this email directly or view it on GitHub.

[sergeybykov]

By 22nd I'll beat jetlag and hopefully won't fall asleep at the Hangout wheel. Richard, if there are any instructions I need to know, please send them my way.

[sergeybykov]

19:00 GMT, right?

[richorama]

Any time you like. I normally go for 7pm GMT (well BST at the moment)

-----Original Message----- From: "Sergey Bykov" notifications@github.com Sent: ‎01/‎05/‎2015 20:14 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

19:00 GMT, right? — Reply to this email directly or view it on GitHub.

[richorama]

I'll write up what I do to organise a meet up.

-----Original Message----- From: "Sergey Bykov" notifications@github.com Sent: ‎01/‎05/‎2015 20:14 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

19:00 GMT, right? — Reply to this email directly or view it on GitHub.

[javier-alvarez]

Can you send a calendar invite for this?

[richorama]

I think the google hangout creates one.

-----Original Message----- From: "Javier" notifications@github.com Sent: ‎01/‎05/‎2015 22:34 To: "OrleansContrib/meetups" meetups@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [meetups] Topics (#1)

Can you send a calendar invite for this? — Reply to this email directly or view it on GitHub.

[sergeybykov]

We are going live in 45 minutes at https://plus.google.com/events/crdjm977pqubv81lgdhqruoqal4.

[yevhen]

@sergeybykov crouching ... :smile:

[sergeybykov]

@yevhen Beer-o-clock already? ;-)