.NET Orleans
dotnet.github.io
dotnet.github.io
Specifically I'm talking about tools like LINQ, dotnet core libraries, VS and VS Code integration, and the standard library and common library packages.
I still think it has a long way to go but its still a huge potential upside, which is to say nothing of how its coming to dominate the games industry as well.
Yes a JS only developer is probably lacks certain experience but I am well versed in Java and have had solid exposure to C#, like they them both a lot, but today would prefer to use TS on backend and front end for any small project. The fact that I can share types and validation code (Joi) on both server and client is really powerful in my opinion. There’s only so much you have time to focus on when you’re working on a small project. Context switching two platforms is a big impediment in such cases.
But Microsoft won't officially do any more since they have Blazor which lets you run C#/.NET in the browser with both client-side WASM and server-side SignalR/websocket running modes. It's much more advanced and functional than React already. [3]
1. https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-S... 2. https://reactjs.net/ 3. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
> It's much more advanced and functional than React already.
I’m sure this is true, but I can’t imagine there’s much of a community around it? The thing is with React you have a huuuuuuge community and ecosystem. You can share code with React Native. It’s so deep...
While React's ecosystem might be huge, the quality trails off quickly and it's pretty messy even with the popular stuff, much of which is to add functionality that every app needs but isn't included in React itself. Blazor already comes with everything included, but can also use the full power of C#, the massive standard library, plenty of 3rd-party packages, and the tight integration with the backend.
I suggest looking at some of the Blazor presentations (by Steven Sanderson the original creator) to get a sense of just how quickly you can build: 1. https://www.youtube.com/watch?v=Khn7sDUSEJM 2. https://www.youtube.com/watch?v=QnBYmTpugz0 3. https://www.youtube.com/watch?v=kLhoRyLxwAE
The closest community project is https://github.com/JeringTech/Javascript.NodeJS and should be a drop-in replacement for `INodeServices`
If you just want V8/JS scripting then there's https://github.com/microsoft/ClearScript
The browser runtime is trimmed down to the APIs actually used, has dynamic async loading now, and it's around the 1.5MB mark which is competitive with the big SPA payloads.
Here's a very old build: https://blazor-demo.github.io/
And a recent build: https://stevesandersonms.github.io/BlazorOnGitHubPages/
Yes you can be smaller with JS but not by much these days, and given the amount of functionality you get with Blazor it's hard to compare on file size alone. Also if you're just making internal apps with controlled usage then server-side is better anyway.
It's 2020 I can't name a single server side known application built in net core.
If you like F#, why not just reap all the functional benefits and write it in Haskell, or Rust which has (arguably) just as strong a functional influence (minus the syntax) as F# does, with the benefit of a stronger type system, and better performance, and these days, probably a bigger community than F# as well.
I'm a big fan of C# and the .Net platform as well. Being able to mix C# code in a project is compelling. If C# had a strong native SSH(I'm aware of netssh, but something a bit more official/active) implementation, and a WinRM/Remoting implementation that wasn't hidden inside the Powershell project, I think there would be a .Net OSS tools explosion..
Bitwarden is a self-hosted lastpass/1password competitor in .NET
You've probably used oauth somewhere powered by IdentityServer, played a game built in Unity, and used a mobile app built with Xamarin.
In fact it remains to be announced what are their plans regarding .NET 5.
There are plenty of enterprise stuff like SharePoint, Sitecore, GUI components based on commercial partners like Telerik and Component One, among many others that are still on an transition to Core.
And for those that already moved there, their stability is still at v1.0 level, better leave the "fun" to others.
EDIT: typos and grammar.
In the consulting business "I rewrote X in Y" blog posts only happen when someone takes the time to budget the project, because there is someone doing the math of developer time x cost per hour.
Then .NET Framework has been Windows specific for 20 years, there are lots of .NET libraries that are thin wrappers over Windows APIs, or interact with COM/UWP.
Porting them to Core means just rewriting everything from scratch, and if they are to remain anyway Windows specific, there is no advantage other than stay on reboot treadmill that Microsoft has started with the UWP/.NET Core (now backing off with Reunion), so they just keep doing .NET Framework as usual.
Spin up an Web API is at most one bullet point among many others.
I feel like a lot of what I see online fits into either SaaS web apps, or well known open source projects / core infrastructure used in building large-scale, distributed systems.
I'm sure there's a lot more out there, but it doesn't seem to get talked about much. Hence, the comment. Meaning if you're interested in coming over to the .NET Core world fr a different background then the things that are missing from full .NET Framework probably aren't of any interest to you.
The roadmap is to collapse both into '.NET Standard' at some point. MS are committed to full cross-platform compatibility.
MAUI (Xamarin rebranded) is only expected for .NET 6, if the stupidity of Blazor on Web Widgets doesn't end up replacing it.
https://stackexchange.com/performance
https://hub.packtpub.com/stack-exchange-migrates-to-net-enti...
And there's definitely nobody can see the current state of their underlying technologies to know about their transitions https://github.com/StackExchange
So ... this all just sounds weird for a startup with a weird name?
/s
Stackshare can be useful to track who is using what, although a lot of folks are not public about it: https://stackshare.io/dot-net-core
Really? I was of the impression that Unity C# is the old, established player in this space, while Godot (which supports C# but doesn’t force it at all) is growing among hobbyists and indies and may eventually pass the current popularity of Blender in VFX and go on to dominate the games industry in a few years or a decade.
The language stack is unmatched in terms of how quickly you can make a high-quality product across many different platforms.
I built an adtech platform doing millions of requests in 2010 in dotnet. Then I did it again doing billions of requests in 2012. Nothing else at the time other than java could come close with the same amount of effort.
But that is over with modern .NET Core. Nothing of above is valid anymore and the result is wicked fast as your link shows as evidence.
I would recommend some early talks from Damian Edwards or David Fowler about ASP.NET Core. They are very explicit about that (in the end they build Katana replacing System.Web on .NET Framework to allow a better ASP.NET MVC performance, which lead to Project "K", which lead to (ASP).NET Core).
Speaking as one fanboy to another ;)
But yes, those tricks are now obsolete and the platform is incredibly fast.
I always got the impression .net was never particularly performance focused: there were some bits you could use if you wanted to go a bit faster, but it doesn't seem designed from the ground up to be fast, and AoT compilation seems to be perpetually on the back-burner.
Compared to other languages like C++ or Rust, which have been built for speed...
Edit: changed my comment because it was a bit too argumentative.
AOT doesn't have anything to do with performance but helps with startup time and packaging. The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.
C++ and Rust are faster because they don't have a managed runtime, and Rust's major innovation was moving as much of the memory management into a strong build-time analysis to ensure it's properly access. You can build low-allocation or more manual memory management with .NET and get very similar performance. RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/
Your comments are surprising since you seem to have experience F# and other languages and yet it sounds like you haven't used any modern .NET version.
Most of the stuff I've written in .net(core) has been in F# and C# (v8) and runtime v3.1. So much pain playing 20 questions with libs whose runtime requirements were thoroughly and widely distributed across all the runtime versions in a quest to get them to co-operate. I guess I'm just not a huge fan of the language in general, it's all a bit too enterprise-design-pattern-clunky-objects and implicit-mutation all the way down, not to mention verbose. I know it's finally, finally getting a half-decent implementation of pattern matching and immutable records, but there's nothing that stands out to me about it that makes me want to use it over literally any other language I know, which I guess is fine as it's primary target is being a "boring" enterprise language, which it excels at.
> AOT doesn't have anything to do with performance but helps with startup time and packaging.
Not sure I'd agree with this: putting code through an optimising compiler like LLVM ahead-of-time means you can apply more performance optimisations for runtime.
> The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.
That's fair, but if you type-system and language design already tells you everything you need to know, you don't need to wait until code gets hot-enough to swap it in, you just pay the compile-time cost and have it go at peak speed the whole time, my argument here might be veering dangerously close to the 'sufficiently-advanced-compiler' argument hahaha.
> Saying "built for speed" doesn't really mean much. .NET created the async Task model that other languages adopted and has all kinds of performance related features from Span/Memory APIs to SIMD vector operations.
Sure, it's got some fast bits but in my experience very few libraries make any use of them and by default most things are heap allocated, with plenty of pointer-indirection right? Compare that to Rust where far more is stack-allocated and numerous other optimisations and shortcuts get applied so the things you're accessing on the heap still aren't too slow. The async-task model is just a model and has nothing to do with actual run-time performance though right? I had a go playing around with Span when I last wrote stuff in C#, but I found it difficult to do much with it as the compiler either wanted way more things to operate on Span-types (some of which was out of my control) or I needed to do things with iterators that required me to turn it right back into a 'heavyweight' IEnumerable class, which kind of defeated the purpose. Entirely plausible I was using it wrong though.
> RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/
Ok that's cool, I hadn't heard of this, I'll check it out.
There's nothing quite like it, and I find myself coming back to it and doing everything faster. The only downside would be a smaller open-source ecosystem (for many various reasons) so you don't get all the "cool" libraries, although you there are more than enough to solve any problem.
It's going to take a few years for Blazor to catch up & have a chance to surpass the Node ecosystem but they have a good shot.
They need more/better front-end specific tooling & a quicker feedback loop with hot reloading. There is some hope that hot reloading will make it in for next November's .NET 6 release.
As Wasm & Blazor improve, I think it has the potential to be what people like about TypeScript but with less setup required or worries about missing dependency support.
The WASM mode is still a little rough but it's rapidly improving. Hot reloading will definitely make a big difference there when it arrives.
> advanced ORMs like EntityFramework and NHibernate
I've used all of these. Rails' ActiveRecord blows all of them clean out of the water.
LINQ has nothing to do with ORMs, it's a generic querying/transform syntax that can operate on any kind of data structure, and it's expressiveness allows it to be seamlessly translated into SQL by EF and others.
Also it's hard to beat the static-typed nature of C#/EF and the fact that entities are just plain classes with no special needs or inheritance. They can be as "active" as you need them while the DbContext wraps everything nicely.
I'm dealing with some rather fun EF code inside triple nested for loops that runs several thousand queries before throwing a validation error. Now, I know that's the devs fault and not EF, but EF made it all just seem like harmless object oriented programming and not set operations.
I almost feel like I'd like EF for write operations, and Dapper for read operations. Strike a balance.
And for the record I hate LINQ to SQL.
(#(1 2 3 4 5 6) select:[:e | x isPrime]) collect: [:e | 2 * e]Ive seen so many awful queries with terrible performance out of EF.
LINQ is cool, and EF is alright if you have a decent team with good practices, but it takes a lot of discipline for it not to turn into a hot mess.
Though I do like it and think it's pretty good, it would really benefit from a bigger open source community. It's picking up, but it is on the backfoot due to starting out with a closed-source philosophy.
- C# and F# are constantly updated in coherently. They have been on a yearly improvement cadence for the past 5 years.
- It's easy to pick up. I wrote 300+ samples for ASP.NET Core (https://github.com/dodyg/practical-aspnetcore)
- It's really a fun framework to develop in.
For all it's other features, I'm really not sure I'd call .net fast. It's got half decent speed, but it's not "woah that's fast"
> - C# and F# are constantly updated in coherently
By which you mean C# gets new features every year, and F# gets thrown enough tidbits to keep it looking alive?
C# gets more features every year than F# because C# is still trying to catch up to F# 1.0. F# 5 got good updates this round (https://devblogs.microsoft.com/dotnet/f-5-update-for-august/)
Every new C# version makes interoperability more of a pain. The C# team have no interest in compatibility with F# and will NIH stuff that could've been taken from F# libraries. One of the biggest pain points for interop is tasks, for which there are half a dozen libraries for F# and everyone uses a different one. There's been an open issue for F# to have native task support for years, but progress is slow.
- Akka https://github.com/akka/akka - Lucene https://github.com/apache/lucene-solr - Aeron https://github.com/real-logic/aeron - Retrofit https://github.com/square/retrofit
Not to mention projects like Apache Spark, Cassandra, Elasticsearch, Druid - Java projects. Many projects (Foundation DB, Scylla DB, I could find more) will have in-house support for Java and not .NET.
The .NET equivalents to these libraries tend to be playing catch up. Xamarin Android will always be playing catch-up to Android's Java/Kotlin APIs for Android. Big machine learning projects like PyTorch and TensorFlow tend to give first-class support of some fashion to a Java API (mostly due to Android). Is there a .NET equivalent to Deeplearning4j? Hadoop? Hive? Kakfa?
In Java there is a proliferation of web projects: Spring, Vert.x, Quarkus, Micronaut, Play 2, Spark Java; Netty, Jetty, Apache. In .NET all you ever hear about is Microsoft projects ASP.NET core; Kestrel, IIS.
Working as a .NET dev, when there is an SDK, if it's not from Microsoft, it's clear the .NET SDK is a lower priority for bug fixes and new features compared to e.g. the Java/Python/etc.
TensorFlow can run on any JVM for building, training and running machine learning models. They have created recently https://github.com/tensorflow/java
PyTorch also supports inference on the JVM but you still need to train with Python. https://www.infoq.com/news/2020/02/pytorch-releases-java-bin...
I think something like Scala will be used in the future instead of Python even for prototyping.
Streaming is also big business on the JVM: Apache Kafka https://kafka.apache.org/ (80% of Fortune 100 companies use it) Apache Flink https://flink.apache.org/ Apache Storm https://storm.apache.org/
Hard to think that .NET ecosystem will ever reach the ecosystem of Java when it comes to open-source.
[1] https://www.cnet.com/news/sun-microsoft-settle-java-suit/ [2] https://en.m.wikipedia.org/wiki/Oracle_America,_Inc._v._Goog....
CoreRT was supposed to bring full AOT to C#, and that project is still in alpha with a disclaimer saying there are no plans to make it production-ready. LLILC, the compiler that targets LLVM, is also not production ready.
Anyone know what's going on?
As someone who isn't a .NET developer, the sheer proliferation of runtimes and platforms is super confusing, and I can never remember what's what between, .NET, .NET Native, .NET Framework, .NET Core, Mono, CoreRT, etc. If this is getting cleaned up, that's great news.
This is sadly totally true.
So instead of a C++ with C# like tooling for doing UWP stuff, now one gets to edit IDL files without any kind of support (you could be using Notepad for what they care), and then you have to manually copy/merge C++ files after being generated.
And on the .NET side .NET Native was looking to be how version 1.0 should have been all along, and now has an uncertain future.
Finally with Reunion, when going regularly on their issues, it seems to be turning into a major reboot, porting what they can into Windows 7 like stack, leave UWP as an improved COM runtime, and pretend that everything else post Windows 8 outside Win32 never happened.
.NET windows/desktop framework stopped at version 4.8 and .NET Core has spent 4 years incrementing to version 3, so .NET 5 is a merger of everything into a single framework again. Mono will still exist since it's used by Xamarin for mobile and Unity for games.
AOT is mentioned in the article and comments, and there's also this big thread in the CoreRT repo if you want to see more discussions: https://github.com/dotnet/corert/issues/7200
Is it a merger or a replacement?
I won't be able to just take my huge legacy .NET 4.7.2 app and just change the runtime to .NET 5 and hit the go button right?
Seems for the app I work on at least the upgrade path is a full rewrite :/
You might be able to get pretty far with just a framework switch. The RC is already out so try it. You'll probably have to update the csproj/sln files at a minimum and fix some known API differences but it's unlikely you need an entire rewrite.
My EF 5, EDMX, ancient dependencies and the like probably beg to differ.
Libaries/Frameworks -> .NET core, .NET framework. Two different versions of the libraries, .NET Core is newer and cross platform but older technologies such as webforms can't run on it, .NET framework supports older technologies but isn't cross platform. Plenty of libraries are usable inside either framework.
Ahead of Time Compilation Technologies -> .Net Native, CoreRT, AOT
Most new devs don't have to know any of this to be productive. Just pick .NET core unless you need to use .NET Framework for backwards compatibility reasons.
I also really like the Rails restful router which is strongly tied to its controllers.
I could go on. I really like that Rails gives me strong, opinionated conventions but also allows me to configure things to be liking if needed.
I want to love .net core - I really like F#. Any other rails dev out there make the transition to .net core?
The default web template is far more spartan than what Rails provides out of the box. The workflow you're talking about can be done by installing packages and configuration (5-10min maximum for experienced .Net developers), and I'd wager good money on such a workflow being available as a "dotnet new" template.
Everything you mentioned can be done with some packages and a few lines of code, and the entire framework does have some opinionated conventions but with much more freedom than Rails. The fact that you can have MVC, Razor Pages, raw controllers, and Blazor all in the same app shows just how much freedom you have.
I think Microsoft is moving in the right direction though. Scott Hanselman has some .net core 101 videos out on Youtube that are good to get up and running.
What I found lacking (at the time) was specifically a better Webpack integration, similar to rails. Also I got used to having rspec, in net core world you have xUnit which is something like ruby TestUnit.
At the start I also found DependencyInjection a bit confusing and also the fact that in Aspnetcore the models/entities aren't like AR models where you have a bunch of validation/instance methods inside it. In .net you try to separate everything in repositories/validators/viewModels.
But yes, unlike Rails, .net won't have an opinionated way on how to do things.
All-in-all I'm quite satisfied with the experience. Though I will say that Rails is still a tad more "batteries included" type of thing.
Right now though, the dev ergonomics and productivity of .NET core are not actually very far behind rails at all, so you can serve your pages in 2ms instead of 200ms without suffering for it.
In some regards actually, perf helps a lot. Running a large bank of tests for example - those are going to complete a LOT more quickly in .NET which means you can iterate faster and have a better dev experience
They're worlds apart. Rails is optimized for day 1, .net core is optimized for day 1000.
Sure, that’s a standard argument for statically-typed kitchen-sink enterprise-marketed languages and platforms like Java/JVM and C#/.NET. But having come in to maintain things on day 1000 (or, in some cases 5000) for projects in such languages and, also, languages that are far less strict and have less features designed to require/support tooling, it's not been my experience that there's really that much of an advantage in practice.
ASP.NET MVC (which is now ASP.NET Core) is a fairly carbon copy ripoff of what rails was back then. Initially I was annoyed about this; there were efforts to run Ruby on .NET via IronRuby and thus get a nice rails-on-windows environment, and ASP.NET MVC came along and sucked all the wind out of that like a tent collapsing. Controllers, Views, Routing are all the same, and like rails can be reconfigured if you prefer.
Later on though, I’m happy with it. A new blank project doesn’t quite have all that stuff, but you can add the postgres driver, migrations, etc with a few lines of code.
You do lose out on all the more advanced Ruby meta-magic things that rails does like with_scope on ActiveRecord, but in exchange you get a 1000x performance boost, and static typing - especially now with null safety in C#8 is really helpful as your codebase grows. The productivity hit you take compared to rails is actually pretty minimal I think, and those other benefits outweigh that and some. I would chose ASP.NET core over rails for any web project at any time these days
Good luck!
I never got the point of Active Record amazement, having used similar teach like 5 years before Rails happened, we just weren't on Silicon Valley.
Yet I don't see .NET getting on Java turf as much as many Internet thinks it can.
It remains mostly a Windows stack (so many enterprise third party are yet to release Core stuff that is actually cross platform), and there are plenty of platforms without any kind of .NET support, yet you will find a Java vendor on them.
Also ironically Microsoft is now a OpenJDK member and they are the ones doing the Apple Silicon support.
The beauty of Java is that it is like C, plenty of implementations to choose from. :)
But I agree. .NET will not replace Java or any other serious language.
SharePoint and Sitecore are .NET Framework only. Only CSOM is Core and Sitecore just released their first Core support last month, and most enterprise projects ends up plugging into them.
Forms, WPF still have issues running on top of core, UWP is stuck on Core 2.1 compatibility and .NET 5 is focused on desktop deployments with UWP future uncertain.
I think you have to specify a domain to make that statement reasonable. I think .NET is used more than Go for example. Maybe more than NodeJs also for server systems. Less than Java. If we compare to C++ it is very much down to domains. I don't hear about many enterprises using C++ for server backend code but of course they exist. And so on. .NET (or C#) may already be "leading" against a lot of other languages and then the question is if the others will replace C# or not. And if it will take some of the market from languages like Java which I think it will but not all.
Basically what everyone usually advocates as "Python" in performance critical stuff, but we get the the productivity and JIT/AOT tooling from Java/.NET eco-system as well.
It’s pretty much as far away from “serious language” as it’s possible to get, but here you are happily using it anyway.
Take your Gatekeeping and get in the sea, thanks
LINQ? Clojure and Scala can offer you much more than LINQ. Java is on par.
dotNET Core libraries? I don't know, I have never heard people complaining much of the core libraries in the JVM world.
VS and VS Code integration? JavaScript and TypeScript has the best VSCode integration, other languages are just supported, including C#, F#, Java, Scala etc. JetBrains IDEs are much more powerful than what VSCode will ever offer. VS is not even cross-platform.
The C# used in game industry is a far cry from the one used in enterprise and I don't think C# is the longterm answer for scripting in game dev.
Example for bad parts: Handling checked exception in lambda, no extension method support, calling ".collect(Collectors.toList())" every time, no real closure support, complex lambda type due to primitive types.
I should mention async/await for C# feature compared to Java.
IMO Scala/Clojure is too much for me, C# is balanced option.
I gave a talk recently on how we use it at Microsoft: https://www.youtube.com/watch?v=KhgYlvGLv9c - the talk is very short and so it does not go into many details, but it gives an overview of some internal use cases.
I really enjoyed the simplistic development model of Orleans compared to SF, and I want to give streams a second chance on a personal project, but I'm concerned that both Orleans and SF RA will be superseded by SF Mesh - do you have any thoughts on this?
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?
Going through the documentation, this is a complete trip. I see some of the original concepts are still intact, but the ergonomics are completely different now. Awesome!
You can read a bit about my use of it here: https://www.realartists.com/blog/ship-20.html
All the code is in GitHub, if anyone wants to take a look.
Just don't make any bugs in your code or you're in for a headache.
The ergonomics of Orleans are so nice in fact, it inspired me to try to achieve a similar effect (any POCO can be invoked across the network) by using IL weaving. It worked, but it's SCARY.
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.
That said, there's also https://github.com/Azure/azure-functions-durable-extension which seems closely related to Orleans, but for serverless.
Durable Functions are great for deterministic synchronization across calls to other Azure Functions. Fan-out, fan-in, function chaining, and similar tasks are best done using Durable Functions[0].
Could you build an actor model on top of Durable Functions? Possibly. I'm not sure why you would do that, though. Azure Functions are already pretty expensive.
[0]: https://docs.microsoft.com/en-us/azure/azure-functions/durab...
https://docs.microsoft.com/en-us/azure/azure-functions/durab...
You all screaming performance and techempower stats don't even realise that C#(ASP.NET Core) is 6th placed on techempower's list when you check the composition of all the various benchmarks.
All of these without sacrificing readability, compile times, verbosity etc.
Or do you want to talk about the agility of the framework, speedy bug fixes, endless innovations and all. Don't even get me started on the tooling. It's unmatched in all of programming. VS2019, VS Code, Rider, dotnet cli etc. Ever heard about Roslyn?
Drop your hatred and check out dotnet's current state before jumping into conclusions.
C'mon, let's be real. .NET is supreme in the streets of code.
- 2016 hn thread https://news.ycombinator.com/item?id=12108336
- the famous Halo 4 talk: https://vimeo.com/111287292
- core dev talk: https://www.youtube.com/watch?v=tsolQ4pKM6U
It supports all languages that compile to wasm.
Very early stage project, though.
References to grains are represented by interfaces and if the machine you're communicating with fails, the grain will be re-activated on a surviving host the next time you need to call it. In other words, they are location transparent and the application won't get stuck in some failure state when a machine crashes.
However, Orleans doesn't seem to play very well with Kubernetes. Kubernetes pods can be uncleanly terminated at any time for any reason. Orleans really doesn't like unclean shutdowns: it will leave behind dead entries in the membership tables, which then cause problems in the future because new nodes would contact dead members and run into errors.
The clustering protocol also seems to assume that all members have stable identities and IP addresses, but that's obviously not the case in Kubernetes, where each new pod has a new identity and new IP address. This can cause members to fail uncleanly, which in turn pushes the clustering protocol into an infinite loop.
Orleans was introduced by one person who has a background in distributed computing. Unfortunately, he's the only one in the organization with such a background. After he left, nobody could debug clustering problems.
> Early in the start-up process and at runtime, the silo will probe Kubernetes to find which silos do not have corresponding pods and mark those silos as dead [1]
This is an experimental fix in a MR [1] that comes 6 years after Microsoft announced support for Kubernetes [2].
> Orleans was created at Microsoft Research and designed for use in the cloud. [0]
I read: MS research developed the concepts of .NET Orleans 10 years ago without having Orchestrators like Kubernetes in mind. Now as an afterthought they have to come up with some patches for it not to cripple on short-lived Kubernetes nodes.
A proper Operator & Helm chart was requested in nov 2017 [3] and the issue still is open. I get the impression that it is either not possible to write a proper Kubernetes Operator without a major rewrite of .NET Orleans or Microsoft has a commercial interest for .NET Orleans not being a first class citizen on Kubernetes.
Whichever it is, I’m not going near a Kubernetes cluster hosting .NET Orleans.
[0] http://dotnet.github.io/orleans/Documentation/index.html
[1] https://github.com/dotnet/orleans/pull/6707
[2] https://azure.microsoft.com/en-us/blog/azure-collaboration-w...
If you want to discuss, feel free to message me on Twitter (https://twitter.com/reubenbond) or Gitter (https://gitter.im/dotnet/orleans).
- why it took up to 6 years for MS to release an experimental fix [1] to run on Kubernetes?
- where I can find the outstanding issue in the release notes that [1] tries to fix?
- why Microsoft doesn't write and release an Operator & Helm chart, instead asking the community?
- if .NET Orleans runs fine on Kubernetes, why is there a need for an experimental fix?
There is no experimental fix, just improvements. Things which can make life easier for developers running on Kubernetes by automating some things (setting addresses), and taking advantage of information that's available in a Kubernetes cluster (whether or not a pod has been deleted) and feeding that into the cluster membership system.
The reason the latter is useful is that it addresses something which can occur during initial dev/test, but which does not come up in production cases: when an entire cluster is deleted and redeployed with the same identity, the new instances try to contact defunct instances for a few minutes as a safety measure. The enhancement is to query Kubernetes to determine if it's worth trying to contact those nodes, or whether they're almost certainly dead.
- why Microsoft doesn't write and release an Operator & Helm chart, instead asking the community?
Helm charts aren't something we see requested often. Perhaps because Orleans is a framework which is embedded into the developer's application and not a service which gets deployed and stands alone (compared to, for example, a database). There are no separate Orleans pods, just the user's application pods. Internal users have been building applications on Kubernetes with their own Helm charts. Microsoft is not asking anybody to create those things, or anything, unless they want them for themselves.
Not true, pods can be gracefully shutdown, see https://cloudblog.withgoogle.com/products/gcp/kubernetes-bes...
> The clustering protocol also seems to assume that all members have stable identities and IP addresses, but that's obviously not the case in Kubernetes, where each new pod has a new identity and new IP address.
Both not true: Orleans cluster managed by a dynamic membership table which could be implemented by various tools(azure table, zookeeper, Kubernetes crds(etcd internally), etc), so nodes don't need static ip addresses also, in Kubernetes, you can deploy application as statefulset, by this way, pods will have stable identities
> Orleans was introduced by one person who has a background in distributed computing. Unfortunately, he's the only one in the organization with such a background. After he left, nobody could debug clustering problems.
Need source and proof for this one
Please don't post ridiculous opinions about things you are not familiar with, both Kubernetes and Orleans.
I have built successful products by Orleans & Kubernetes since two years ago, and now Orleans get better integration for Kubernetes than that time
edit: formatting & typo
So it was quite an eye opener to read about how Orleans introduced Virtual Actors, activations and placements of actors and how these are exactly the things I've thought about over the years. I've read about e.g. the classic Erlang actors, but the concept of virtual actors in Orleans really fit my model.
I'll be sticking with Python, but starting with the Orleans paper has lead me to quite a few similar systems: https://www.researchgate.net/publication/233416056_Orleans_C... that reference it.
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?
Besides that the typescript type system is insane. It’s cool to hear about discriminated unions though.
This is addressed since C# 8.
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 notably by game studios, such as 343 Industries and The Coalition as a platform for cloud services behind Halo 4 and 5, and Gears of War 4, as well as by a number of other companies.
> Orleans was open-sourced in January 2015, and attracted many developers that formed one of the most vibrant open source communities in the .NET ecosystem.
Orleans itself is quite nice, I've used it a few times on some smallish things. Looking at using it in anger for a large distributed backend system in the nearish future.
Orleans DDoS?
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.
- 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)
- Akka and Erlang have the concept of Supervision. i.e. An actor may have a child, and if that child crashes, the (parent) is notified and may choose how to react (restart child, don't restart child, crash itself)
- Orleans may allow more than one activation of the same grain at the same time. A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
- Orleans can magically scale out with the cloud (If you're running them on Azure.) Erlang/Akka you'll have to deploy your new nodes.
I thought Erlang only guaranteed that if the processes are on the same node. Is that not correct?
http://erlang.org/faq/academic.html#idp33052176
http://erlang.org/pipermail/erlang-questions/2017-September/...
For a long time I was curious how Akka Artery preserved message ordering for it's 'dedicated large message' lane. in short it really just means you are dedicating a specific TCP or Aeron connection dedicated to those actors, there's no magic ordering sauce underneath. (just a little disappointed to find that out, but appreciate the simplicity upon consideration.)
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.
Yep, although it's not typically as bad as it sounds even in Akka/Erlang; TCP gets you most of the way there. It does however become a problem when want to try to scale 'out' (i.e. use multiple links for message prioritization, etc.)
> 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.
For sure, Akka doesn't do it for you. I think one of the biggest yak shaves in setting up would be picking your partition strategy and making sure it works the way you intended. But, once you do it's fun to watch the metrics graphs move when you cut nodes. :)
> 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.
Yeah supervision can be a bit weird to explain properly.
It all goes back to that first point though; Orleans is a very guided implementation and has very nice, C#-like bindings. Akka is in my view (Akka.NET project contributor, have also written some frameworks and in-production business apps using) more of a 'Toolkit'. You can see this in the various modules that result from it, such as Akka Streams, Spray/Play. Lagom, etc. Use Orleans if you want to write distributed code in C# quickly and within it's constraints. Use Akka if you want to write distributed code or just a quick and dirty Message-passing Scheduler/kernel.
So you're telling me that during a network partition, Akka will somehow know that the entity actor is alive and well in (one of) the other partition(s) and won't start a new one?
Also worth noting that depending on the pattern used to send to the entity, there is a possibility of dropped messages during such a case.
- 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.
So an honest question: what exactly do people see in VS as being so outstanding, that other IDEs lack?
- The architecture modeling tools.
- The GPGPU debuggers
- Data structures visualization
- REPL and immediate window
- Graphical visualization for tasks, processes and their dependencies
- being able to visualize binary libraries in a way similar to .NET ones
- the GUI designers, with live changes support and introspection
- being from the same company that actually produces the OS and dev tools.
I suppose it's always going to come down on each developer's specific use cases and needs, and the average rating of the IDE will be a mix. I've just been consistently surprised with the positivity towards VS in _some_ areas, where my experience was a polar opposite. As an example, working with any sort of "relatively up to date" client side web UI tech (Angular, React) between 2014 and 2018 in VS was an exercise in pure frustration, whereas e.g. VS Code was not. At that time I would not have put VS in the top 3 for that environment, and I frequently wonder whether people just loved it out of seeing the world with MS glasses on, or what.
How big of a task would learning this framework be? Is the documentation good enough? Sounds like it could be a good option for a game's network backend.
1: https://github.com/dotnet/orleans/graphs/contributors
2: https://dotnet.github.io/orleans/Community/Who-Is-Using-Orle...
I am learning Orleans at the moment. I've created about 12 sample projects in Orleans as I am learning the concepts. Most of the samples are very small and can be run in one program thanks to the ability to host Orleans and ASP.NET Core Web server together.
I'm assuming it's proven scalability? The grain/silo virtual actor model was always cool though the project abandoned it in the end.
Hmmm, getting a very strong Microsoft Enterprise Library vibe.
The Microsoft Enterprise Library is a set of tools and programming libraries for the Microsoft .NET Framework. It provides APIs to facilitate proven practices in core areas of programming.
Packed full of Best Practices and more Enterprisey than Kirk, it was inscrutable to me.
Based on the novel Virtual Actor Design model, I assume Orleans is Design Patterns all the way down.
Would you mind expanding (or linking to a documentation) on how Orleans enables reliable systems?
I watched this talk (https://www.youtube.com/watch?v=9OMXw0CslKE) that uses an example web application called Smilr to demonstrate some of the features of Orleans. However, that talk doesn't really go into detail on how failures are handled.
For example, in the Smilr app, each 'Event' grain is responsible for notifying an 'Aggregator' grain whenever it comes into existence (or an existing one has its updated). What happens when a call from Event grain to Aggregator grain fails? Who is responsible for retrying?
Link to the code - https://github.com/benc-uk/smilr/blob/master/orleans/Grains/...
I'm mostly convinced F# is there so MS can say "you can do functional things, yeah!" without needing to make a meaningful effort.
There's the traditional client/server scenario where you distribute the load horizontally across many servers. If most of the server computation is stateless, and all the state is stored in the database, then you can use either the FaaS or the actor model.
Then there's the client/server scenario where the server computation is stateful, in which case you shouldn't use FaaS. You could still use actors though. Isn't this where Orleans sits?
Then there's the peer to peer architecture where all computers run the same code, whether they're in the cloud or on an end user's laptop or phone. Does Orleans make sense in this case?
The doc predates ACID transactions support in Orleans, but it talks about the Virtual Actor model vs the Akka model in general.
At the end of the day, I think Orleans and Akka are conceptually different types/notions of what an actor framework is.
> Orleans uses a different notion of identity than other actor systems. In other systems an “actor” might refer to a behavior and instances of that actor might refer to identities that the actor represents like individual users. In Orleans, an actor represents that persistent identity, and the actual instantiations are in fact reconcilable copies of that identity.
With Akka you manage objects actively, much like memory in C, with Orleans your objects behave much like normal Dotnet/Java objects, they are just distributed and must use async methods. Orleans adds a layer of management, where it will tear down and re-instantiate objects as required, distributes them in the cluster, etc. As a programmer you don't have to worry about it, it's all managed by the runtime.
I've written a lot of Go and there are plenty of faults but I'm curious why you consider it 'constant spaghetti' apparently in the same class as JS.
Go is still far better than JS, but both are behind in modules, packaging and overall structure as compared to .NET. gofmt is nice though, more languages should have that.
- Getting packages installed: trivial
- Getting clean builds: trivial
- Build and run works near perfectly
In comparison .net seems designed to be used _only_ via Visual Studio:
- Why does it re-download the packages each time I ask it to build?
- Why does VS freak out sometimes when there's a terminal window left over from a previous run?
- Why does VS freak out so thoroughly when something changes under it.
- Sometimes it just caches your previous build and thinks it's perpetually broken no matter how many changes you make, restarting seems to be the only option.
- Getting dotnet tools to work from the command line (the way Cargo/Yarn/Julia/Pipenv/etc do) was a confusing affair fraught with instructions like "oh you've got to into this XML file and set these random configs and tell it where x/y/z dll is".
That's before we get to the whole disaster that is "add this as a reference to your project". No programming language has caused me quite as much frustration as C#/.net manages to.
We use it all the time, no VS required. You don't have to edit any XML files today, and can use a simple editor like Visual Studio Code or notepad if you want.
Do you have some big old solution that you're working with?
Are you using Nuget?
Does it not do that for you?