Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 17:53
    Aaronontheweb closed #3972
  • 17:53
    Aaronontheweb commented #3972
  • 17:53
    Aaronontheweb closed #3976
  • 17:53
    Aaronontheweb commented #3976
  • 17:40

    Aaronontheweb on dev

    cleaned up some samples to use … (compare)

  • 17:40
    Aaronontheweb closed #3975
  • 16:33
    IgorFedchenko synchronize #3973
  • 16:31
    IgorFedchenko synchronize #3973
  • 14:04
    wsvdyk opened #3976
  • Oct 14 21:02
    Aaronontheweb synchronize #3975
  • Oct 14 21:02
    Aaronontheweb opened #3975
  • Oct 14 20:11
    IgorFedchenko commented #3973
  • Oct 14 20:10
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 19:42
    IgorFedchenko edited #3973
  • Oct 14 18:08
    Aaronontheweb commented #3937
  • Oct 14 17:27
    Aaronontheweb commented #90
  • Oct 14 17:26
    Aaronontheweb commented #90
  • Oct 14 17:25
    Aaronontheweb assigned #90
Arjen Smits
@Danthar
Hmmm. I don't know. But im not sure if what you are saying is correct. I saw an Orleans screencast a while back, from the Halo team, in which they showed off some Orleans code. And although it all felt like Voodoo magic back then (which became alot more clear since I started with Akka). I do distinctly remember them talking about a Host which took care of all the Distributed and Partitioning stuff.
Or maybe I am misunderstanding what you mean with the 'parts merged together' bits
Roger Johansson
@rogeralsing
Orleans does the magic partitioning / always available parts, and they are also an actor framework.. I think that should be separated
Arjen Smits
@Danthar
Ow you mean on a framework level. Hmm. Maybe they felt that that part is, in terms of implementation, so closely married to the Orleans Actor framework, it made no sense to put it in a separate framework. But thats just conjecture on my side, however its the only reason I can think of.
Should be interesting to check out the Orleans code to see if thats true.
Bartosz Sypytkowski
@Horusiath
IMO Akka was always a middleware framework. It is harder to learn and requires an explicit management from the user perspective, but also gives you enough space to develop higher level abstractions (such as streams, virtual endpoints, cluster sharding and many others) on top of it. But you may still dig deep down at any time when you want true control and speed and this is something you'll never get with frameworks, which have started from those higher level concepts as a base line.
David Smith
@smalldave
@Aaronontheweb I'd wait before pulling in RemotingTerminator changes. Working through RemoteNodeShutdownAndComeBackSpec
Want me to close the pull request?
Aaron Stannard
@Aaronontheweb
@smalldave yeah that'd be best for now then
Aaron Stannard
@Aaronontheweb
@rogeralsing @Danthar @Horusiath yeah, that's a design decision with Orleans that I feel is very limiting - the whole thing feels extremely over-engineered to begin with, really. Actors are just tools that don't have any inherent CAP bias, no more than OOP objects having them. Orleans was built for something specific - single apps that are meant to be clustered with high availability.
Orlean's biases don't even really allow for you to network multiple Orleans code bases together without doing some really hacky shit dotnet/orleans#211
so you can't do anything like my WebCrawler Akka.Cluster sample, which uses individual roles as microservices, without having to host your connection to each service in a separate AppDomain
but you know - anything that gets .NET developers in a headspace where they're actively looking at something like the actor model is a good idea in my book
it'll raise the state of our art
Roger Johansson
@rogeralsing
@Aaronontheweb tbh, CAP is only applicable in multi node/system environment (as the definition is how the nodes/system behave) and a single actor is never ever present on multiple machines (that would be different actors) so even bringing CAP up when talking about how actors behave indicates that there is something iffy going on.. (read multiple instances of the same thing)
Bartosz Sypytkowski
@Horusiath

Akka and Orleans are both very mature projects (both around the same age)..

ORLY?

Roger Johansson
@rogeralsing
Maybe they were invisible for 4 years?
Bartosz Sypytkowski
@Horusiath
I don't want to be arrogant or start a flamewar, but to be honest, Akka.NET is based on concepts from Akka, and in further line from Erlang, both of them are heavily battle-tested in hundreds of applications over the course of almost 30 years in total. Orleans (and now Bioware's Orbit) at least for now are both 1-project based, and their are not core part of their projects - neither Halo nor DA:I are multiplayer-based. And while they introduce some incredibly useful ideas, I think it's still not a fair comparison.
And I'm not an Orleans hater - I want to see this framework growing. Variety is good for everyone.
Aaron Stannard
@Aaronontheweb
@rogeralsing yeah I think you and I are saying the same thign
actors are actors - CAP theorem stuff only plays a role when you start distributing them across multiple processes
Roger Johansson
@rogeralsing
Exactly
If orleans removed the broken actor constraints and just exposed always available endpoints, i would love that.
Aaron Stannard
@Aaronontheweb
and TBH, I really wish people who talk about distributed systems stuff would stop pigeonholing on CAP - yes, for the love of god, we get it. Every system has trade offs that have to be picked carefully and deliberately. Not a fundamentally different exercise than making tradeoffs in any other software system (concurrent, embedded, etc...) - just yet another new domain where developers get their butts kicked by the laws of physics and economics over time.
Roger Johansson
@rogeralsing
And let devs decide what to expose on such endpoint
Aaron Stannard
@Aaronontheweb
to your point @Horusiath - Orleans has an in-house project for many years
was*
so it's "mature" from a wall clock time perspective
but not very "mature" from an odometer perspective
Orleans has one success story
so far, hopefully they have more!
Akka has tens of thousands
as it's been open and heavily used by lots of people who are not Typesafe for years
technically speaking, Akka.NET has been publicly available longer than Orleans
they have an interesting interpretation of the actor model, although what they do does not stick to the "actor model" as it's defined in the white paper
Akka.NET is ultimately an unbiased framework - you get the actor model as a single process, a couple of remote processes, a whole cluster of different processes, or clusters of processes that use persistence for greater consistency
and lots of other combinations
Orleans is a piece of off the shelf software built for specific types of distributed apps
and has powerful tools for doing that
but you give up a lot in order to get those tools
Roger Johansson
@rogeralsing
btw. offtopic, but can you take a crash course with me on our cluster supprt? thats the module I know the least about tbh.. I know how to start up clusters and do routers, but no more :P
Aaron Stannard
@Aaronontheweb
haha, sure thing
Roger Johansson
@rogeralsing
not now that is, some day
Aaron Stannard
@Aaronontheweb
I gotta head into the office and get some lunch (probably not in that order)
released Helios v1.4 this morning
has your Mono support
Bartosz Sypytkowski
@Horusiath
we need to distribute some more learning materials about cluster and persistence
Roger Johansson
@rogeralsing
nice :)
Aaron Stannard
@Aaronontheweb
going to send a PR that turns it on in Akka.Remote
@Horusiath yes we do
I took a look at the persistence bits for the first time last weekend