No F# support :O
.NET Orleans
71–80 of 287 posts
Re: .NET Orleans
#72Earlier quoted context omitted.
"in anger" typically means for a real-world, serious project.
Is this a Britishism? I find Americans often are confused by it when I use it.
I use it too much and it has caused consternation with both American and Egyptian colleagues. Not sure what to reprogram my brain to use because it’s pretty ingrained at this point.
Re: .NET Orleans
#73Earlier quoted context omitted.
Maybe I'm looking in all the wrong places, but I'm having a surprisingly hard time finding hardware requirements. I love that with Erlang I can throw an experimental app on Digital Ocean for just $5/mo and see if it gets traction. How much more resource intensive is Orleans and what kind of resource usage should I expect as I scale up the number of actors?
You can run Orleans on a single host or many. In fact I believe we do have a host in production running Orleans by itself that is the equivalent of a $5/mo DO box. Resource usage scales with network activity in my experience. I think there are benchmarks around, but generally the scaling factor seems similar to conventional networking models.
We have a pair of machines for resiliency, but on test and staging environments we run many times the services and experiments on one box with many other services without a problem, it maybe need a bit more memory for the .net virtual machine vs the erlang one, but totally doable with a basic machine.
Re: .NET Orleans
#74> Orleans builds on the developer productivity of .NET
As someone who has developed with .NET (using VB, C#, F#) for almost 15 years, I am not sure if I would still advertise .NET as something focused on developer productivity, when in the context of introducing bleeding edge tech. It is a great framework, but I've found much more productivity with Elixir after just 1 year of using it. C# still suffers from statefulness, null references, and boilerplate code, even after newer versions of the language provide some tools to reduce those.
F# is a good alternative to C# if you want to stay in the .NET ecosystem and reap the benefits of functional programming, but I found the compiler to be very slow, 3rd libraries poorly documented, the language excessively complex, and 3rd party IDE support to be limited (as of version 2.0 anyway).
Is developer productivity still a focus of .NET?
Re: .NET Orleans
#75> It was created by Microsoft Research and introduced the Virtual Actor Model as a novel approach to building a new generation of distributed systems for the Cloud era. Okay, sounds like an academic, Microsofty take on Erlang's Actors? But from docs, sounds like it's at least used in practice at MSFT: > Since 2011, it has been used extensively in the cloud and on premises by several Microsoft product groups, most not…
Academically (And, to some extent, practically speaking) Orleans Virtual actors aren't the same as Erlang (or Akka) actors. Major differences: - Normal actors are pretty flexible, can work in local or remote contexts. Orleans is probably best described as Sharded Actors, It's a 'guided' implementation of Actors compared to Erlang or Akka where you are given a toolkit and have to build out what you intend to do. - Orl…
> Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order)
Ordering has a performance cost. It needs to either be maintained at all levels, or reconstructed from unordered messages at a later point. Even something simple like an m:n thread pool scheduler can ruin ordering guarantees. My view (Orleans core developer) is this: if you want ordering, await your calls. That way, you are guaranteed ordering regardless of any message reordering that can occur in the scheduling or networking layers, or due to failure and recovery of a host. So you can choose when to pay that cost and when to reap the performance benefits of not paying it (by firing off multiple calls in parallel).
> A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
Likewise for Orleans, but the caveat of a "stable cluster" doesn't do much for users. "Stable cluster" falls apart frequently in real scenarios, which can be as simple as a single machine being abruptly restarted. Developers must account for the error scenarios.
> Akka and Erlang have the concept of Supervision.
Orleans does not have supervision, since each grain stands on its own (no hierarchy) and have an eternal nature (managed lifecycle). Grains are not destroyed when a method throws an exception: the exception is propagated back to the caller and the caller can use try/catch to handle the exception. This is similar to what .NET developers are used to, since regular objects are also not destroyed when a method throws an exception, and the caller is able to handle the exception. My belief is that this kind of exception handling is usually appropriate, since the caller has context which can be useful in handling the error. The developer can also write per-grain or global call filters which can operate on all calls and handle any exception, so if that's preferred, then it's available.
Re: .NET Orleans
#76`Orleans builds on the developer productivity of .NET` - could someone familiar with NET development specify what those things might be? I've never used .Net and would love to find out what it does better/worse/different than other frameworks. Thanks!
Let's see:
- best in class IDE
- best in class debugger
- excellent cross platform support
- very fast compilers
- a robust library ecosystem
- no arguments over how to publish or import those libraries
- a build system that just works
- and all without having to install tons of third-party, fly-by-night projects.
Re: .NET Orleans
#77`Orleans builds on the developer productivity of .NET` - could someone familiar with NET development specify what those things might be? I've never used .Net and would love to find out what it does better/worse/different than other frameworks. Thanks!
Let's see: - best in class IDE - best in class debugger - excellent cross platform support - very fast compilers - a robust library ecosystem - no arguments over how to publish or import those libraries - a build system that just works - and all without having to install tons of third-party, fly-by-night projects. I've worked in lots of different environments. .NET is the only one I've been able to leave, come back t…
Thanks!
Re: .NET Orleans
#78> Orleans builds on the developer productivity of .NET As someone who has developed with .NET (using VB, C#, F#) for almost 15 years, I am not sure if I would still advertise .NET as something focused on developer productivity, when in the context of introducing bleeding edge tech. It is a great framework, but I've found much more productivity with Elixir after just 1 year of using it. C# still suffers from statefuln…
Asking developers to learn an entirely new language or ecosystem isn't exactly my idea of productive. ;)
Re: .NET Orleans
#79Earlier quoted context omitted.
Totally off-topic, sorry: How did that name come about?
Microsoft Research has a tradition of naming projects after cities. Eg, if you type "microsoft research project" into Google (Bing appears to work better for this) and let it autocomplete, you can see some other projects which appear to be named after places: malmo, athens, tokyo, and others.
Monaco also
Re: .NET Orleans
#80Orleans is awesome and the virtual aspect of the actor system is something that I have found to be missing from many alleged comparative libraries (Akka, Actix, etc.) It is really the key selling point: run an Orleans cluster and then you can forget about networking altogether (not entirely true, but truer than you may believe.) Just don't make any bugs in your code or you're in for a headache. The ergonomics of Orle…
> Just don't make any bugs in your code or you're in for a headache. Have you taken a look at this? https://microsoft.github.io/coyote/ https://microsoft.github.io/coyote/learn/overview/what-is-co... It's a tool by Microsoft Research to detect concurrency bugs in code.
I feel like the documentation (or something) could be improved there. I've never been able to get it to find a bug.
That said, there's also https://github.com/Azure/azure-functions-durable-extension which seems closely related to Orleans, but for serverless.