akkadotnet/akka.net

Port of Akka actors for .NET

Natan Vivo

@nvivo

if you want to abstract per repository, then you can use all your ORM inside that actor

Nikita Tsukanov

@kekekeks

in this case I'll have to do everything in one god-class

Arjen Smits

@Danthar

@nvivo true. but if you are using an ORM, access to that level, for that kind of manipulation is abstracted away

Natan Vivo

@nvivo

the point is that there is not a single way to do it. akka don't require you to stop using an orm

depends on the orm right?

Arjen Smits

@Danthar

true

Joshua Benjamin

@annymsMthd

One of the main things to note here is the Actor Model != OOP. There are fundamental differences in the way things are modeled and architected.

Nikita Tsukanov

@kekekeks

I mean, different types of actors can share a single resource

jcwrequests

@jcwrequests

Get rid of the ORM and use Event Sourcing :)

Natan Vivo

@nvivo

jcwrequests

@jcwrequests

Or use a micro ORM

Nikita Tsukanov

@kekekeks

Well, show me how to do full text search with event sourcing effectively

Bartosz Sypytkowski

@Horusiath

there are plenty ways to do it. I've got idea, when db connections are distributed using token pattern - there is an actor which holds pool of tokens/db connections, and passes them on demand to other actors inside the same actor system, actors which needs a db access, ask provider wth token request and release the token after their job is done

however it's only an idea, I didn't test it yet

Natan Vivo

@nvivo

@kekekeks what @annymsMthd said is completely true. the thing to realize is: Akka has 5 years of battle tested implementation working for lots of people in most varied environments. It's more about understanding how you can do it than anything else. the model itself doesn't restrict much, but you need to change your application architecture to embrace it.

Nikita Tsukanov

@kekekeks

I don't see why it can't be done with a dispatcher that just limits the number of threads

Arjen Smits

@Danthar

@nvivo Thats very true

Natan Vivo

@nvivo

it's not that it can't be done. it's more that it shouldn't =)

dispatchers control how threads are used. you can run 10 queries using a single thread if you're using async

Arjen Smits

@Danthar

@kekekeks The dispatcher is not meant for solving those kind of problems

Natan Vivo

@nvivo

you shouldn't require messing with threads only to control connections

(that's exactly why I'm trying to come up with some reasons why someone should touch dispatchers - we need some good examples on why one would care about that)

Arjen Smits

@Danthar

Honestly @nvivo I think that if the default dispatcher is properly optimized. The list of scenario's of wanting to implement your own is very small.

Natan Vivo

@nvivo

I agree

Arjen Smits

@Danthar

And thats besides the fact that implementing your own dispatcher if fraught with all kinds of subtleties

Natan Vivo

@nvivo

just so you understand, I'm rewriting the docs to be more "human readable"

Arjen Smits

@Danthar

Yes i know :) been lurking here for days, Just heaven't been very active due to.. stuff

Natan Vivo

@nvivo

currently, if you go to the Dispatchers docs, you can read the entire thing and there is nothing there saying what it actually does and why you should change that

Bartosz Sypytkowski

@Horusiath

I've already proposes an experiment for custom dispatcher built on top of Hopac to see, if there is a possible performance gain

Arjen Smits

@Danthar

iv'e been eyeing the DI examples doc as well. That could use some love.

Hopac. yeah that should be interesting

Natan Vivo

@nvivo

the official akka doc is more like "integers: we implemented using a custom machine architecture where bits are randomly swapped bla bla bla " - when they could just said "they are numbers"

you don't notice after some time. but for people learning, it's a lot of words that don't mean a lot

Bartosz Sypytkowski

@Horusiath

I mean a lot, when you have to deep dive into internals or have some problem

Natan Vivo

@nvivo

all I got from the docs is "it's the engine that makes akka tick".. all the rest I'm going through the source

yep, exactly

I agree they are useful. but it's not what akka.net needs to attract new people

I tried to explain akka.net to some friends, they have a lot of questions that I only know because I'm here everyday and reading the issues and going through the source. it's not a good path for everyone

Arjen Smits

@Danthar

Yup. And not everything is updated for 1.0 yet. Or so it seems. Sometimes hard to judge, other than the fact stuff could be more clear.

Natan Vivo

@nvivo

writing code is easy. it's much harder to document it =)

Arjen Smits

@Danthar

heh, they respond with 'thats very interesting' and leave it at that :P

they deal with very different problems than me :P

Natan Vivo

@nvivo

my wife calls me the king of nerds, and I come here and I see I'm not half of what it takes to code some of this stuff haha

you guys win hands down

Arjen Smits

@Danthar

I know the feeling. In the land of the blind, the man who can see is king

Natan Vivo

@nvivo

:-p

Arjen Smits

@Danthar

And the fact that this profession has an huge amount of interest areas

jcwrequests

@jcwrequests

@kekekeks Check this out https://skillsmatter.com/skillscasts/4081-greg-young-4081

Nikita Tsukanov

@kekekeks

Oh, thanks

jcwrequests

@jcwrequests

I have been playing around trying to find a good way to do stateful actors in a hierarchy. After talking with @Aaronontheweb that HashPooling was not a good idea so I came up with a sample project. Besides adding become logic I was wondering if anyone had any thoughts or criticism on how to model this using Akka.

Where communities thrive

People

Repo info

Activity