If you can write a sentence "X are called Y", and X is more well-known, drop Y.
"You can then send messages to the grain by creating a proxy object, and calling the methods: var grain = GrainClient.GrainFactory.GetGrain<IMyGrain>("grain1"); await grain.SayHello("World");"
var brain = BrainClient.BrainFactory.GetBrain<IMyBrain>("brain1"); await brain.Say("WTF");
I'd been away from .NET/C# for a few years and came back to find that they dialed the abstraction level to 11.
I adore C# as a language but I find myself increasingly alienated by its generally accepted coding style.
I find that Microsoft's products have extremely unintuitive naming schemes at both a low level (language, standard libraries) and a high level (.NET product word salad naming schemes, Office 365 referring to a diverse and inconsistent range of products...).
The skeptic in me thinks that this may be an attempt at educational lock-in.
The lines between marketing and technology have definitely been blurred.
See also:
iTunes (OSX), iTunes (iOS), "Music" (iOS), Apple Music, iTunes Match, Genius and the iCloud Music tab. Podcasts and videos are also all in there somewhere, know what dear user, you figure it out k?
"Say, Steve, what have you been doing last year?" - "Welp, just making sure things work, fixed some bugs, documentation, took customer calls. The product essentially works, people love it". "Wait, so we haven't shipped any new features, hmm, ok...".
vs the response of "We implemented fizz, bar, quux features. We tore down old zig and added zag instead. It is really the same as old zig, but now look green and re-written with latest framework we saw in HN headlines". "Oh great, you get a promotion and a raise".
I am being a bit silly, but it is only half-joking, it is how software industry often works.
Let's break the problem down.
You have a language that doesn't natively support actors or message passing. You can solve this by having the developer stub each method (`this.DispatchActorMessage(...)`) or you can implement the interface on behalf of the developer (`Factory.CreateProxy<T>()`). Microsoft doesn't always use the runtime emit approach and, as someone who has used both approaches[1][2], runtime emit is far preferable. This means that something in your code has a responsibility to create actor proxies. That's the first concept: the responsibility to create actor proxies. Not only that, but so far as Reliable Actors go the proxy needs to do quite a bit of work: actors can be rescheduled to another machine and the proxy needs to continue representing that single durable instance.
You also have context: "which cluster controls this actor?" Depending on your scenario you might be able to assume that there is no context. Microsoft cannot make these assumptions because federation is quite important in the enterprise. In fact, the ability for Reliable Actors to have context [will] allow our customers to extend our product without us worrying about noisy neighbors (they are in charge of their own actor cluster, we simply federate to it). Additionally, there are scenarios where the consumption of an actor occurs outside of the context. For example: calling an actor from a GUI app.
In order to create the actor, you're going to have to use the object with that responsibility (unless you fancy doing the emit yourself): `ActorFactory.Create<IBrainActor>()`. You then need to pass in the context. Orleans uses a `Client` instance (which should make sense to .Net developers), while Reliable Actors pass the context into the `Create` method. So either: `Context.Factory.Create()` or `Factory.Create(Context)`. Nothing more than a stylistic choice necessitated by the requirements that Orleans and Reliable Actors don't share.
The goal here is not to replicate Erlang. It is to make a framework where developers can write distributed systems with a low amount of ceremony. Actors so happen to be the best candidate as a primitive but are most certainly not the be-all and end-all of Reliable Actors (which were inspired by Orleans, so I assume the goal is the same for Orleans). In that way, it makes some things far simpler than Erlang[3] but there's always a cost to that. If distributed systems is the primary goal, then you're going to have overhead if you are not creating a distributed system.
If you're talking about terrible naming, that outright I can agree with. Orleans, however, is no more and no less abstracted than it needs to be.
[1]: https://msdn.microsoft.com/en-us/library/system.diagnostics.... [2]: https://azure.microsoft.com/en-us/documentation/articles/ser... [3]: http://erlang.org/doc/reference_manual/distributed.html
I must confess that I sort of lumped several criticisms together there, conflating API nomenclature, with product nomenclature, with abstraction, as one tends to do when speaking semi-casually.
All C#/Java style static typing code not only looks like that, but often calls it "best practice."
Worth noting that "await" use is quite elegant in what it does here.
e.g. javascript classes/inheritance/OOPs in general.
var grain = GrainClient.GrainFactory.
GetGrain<IMyGrain("grain1")
await grain.SayHello("World");
var brain = BrainClient.BrainFactory.
GetBrain<IMyBrain>("brain1");
await brain.Say("WTF");
GrainPid ! "HelloWorld"
BrainPid ! "WTF"Otherwise it's just
await grain.SayHello("World");
grain1 ! "HelloWorld"
brain1 ! "WTF" do! GrainPid <! "HelloWorld"
stilll a bit more verbose than erlang though
Not to mention that the standard OO cult of unit test / mock everything and make everything "reusable" leads to such shitty designs that almost fall out naturally from the language/paradigm. Oh and the one class per file with 3 method interfaces and 10 ceremony lines with namespaces and import definitions/braces.
I prefer C# over Java, and in some cases even over F# (it's slightly lover level and therefore it's simpler to control for things like heap allocation) but it usually is that verbose and crazy in the real world from my experience.
Not sure I'd call it a cult. From an F# perspective I do it this way:
* REPL-driven work to get it up and running
* Unit tests to protect what needs to be correct against change
* Mock the service boundaries
* Expose object-oriented layer to C#/VB consumers
Unit tests, mocking, and reusability are good things. Overuse (e.g., mocking to make sure that X calls Y in some business logic engine) is just what it is - overuse. Users of functional languages have their own problems, like suffering from code golf and over-using partial application. I wouldn't call one any worse than the other, it's just the functional crowd is smaller so you see it less.
I agree that both have their own issues but I do think one is better than the other, F# is more succinct (without turning in to code golf) and (actually) being multi paradigm avoids cases where OO just doesn't fit well. With micro services, actors, distributed computing, etc. those cases are expanding.
This is the bad coding style I'm talking about... C# is pretty great but it cant stop people from just writing more for no reason.
You're calling the global reference, asking it to give you a proxy to that object, and you need to mention somewhere in the line what type you expect. Without a stronger type system or a complete abandonment of type safety, the most you could do is shorten this by 1 term and move the type from the template term to the left (something has to assert the programmer expects IBrainStuff).
The only other way to do this is explicit code generation (ugh) or implicit code generation (e.g., F# type providers). Which is why in a sibling comment I mentioned I think that an F# binding to this library would be generally more acceptable for people who dislike that kind of abstraction, because the type system can do a lot more to help.
Erlang's model of actors and messages isn't "enterprisey" and this isn't "enterprisey" code, this is just "sufficiently complex OO code." If you like strongly typed OO languages, this style of coding is your nemesis and your hero at the same time.
Preferably, all established terms should be replaced by buzzword candidates.