You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Part of the goal for Akka.NET v1.6 is to be able to get Akka.NET to run everywhere:
Games: Unity / Godot
Mobile: iOS / Android
Embedded Systems
x64 / x86
ARM
One of the major advantages Akka.NET has over Orleans et al is our versatility - we're not dependent on external cloud infrastructure in order to run. Akka.NET's ability to run in a stand-alone .NET process with in-memory messaging is a tremendous source of value for developers. We should lean into this.
The future of .NET is to expand beyond Windows and even x64 architectures - Ahead-of-Time Compilation, "AOT," is what will open the door for Akka.NET to be able to run on an even larger number of platforms more efficiently than it can today. So for v1.6 we are putting "full AOT support" on the critical path.
Requirements
Where are the problem areas that prevent full AOT support today? My AOT canary implementation on TurboMqtt highlights some of the big ones: petabridge/TurboMqtt#25
Newtonsoft.Json and default System.Object serialization - we are already planning on moving to Roslyn Source-Generator powered serialization in v1.6, which should address this issue.
Props and its use of NewExpression - this is a no-no. We might need to go to more basic Func<TActor> implementations or other ways of specifying Props without using a NewExpression. Worth noting: NewExpression has been a source of perf issues as well.
All of these will need to be addressed, gradually, by leveraging tools like the Setup class (replaces HOCON-driven Type loading with static-linking-friendly loading) and changing the way some of Akka.NET's built-in components attempt to load configuration.
Things Users Need to Do To Prepare for AOT
If you care about AOT, please read the next sentences carefully:
The default ActorSystem.Create experience, with no custom plugins / Akka.Remote / Akka.Cluster / Akka.Persistence et al, will be automatically AOT-friendly out of the box;
Is AOT possible at all right now? I'm learning F# with an avalonia side project and I'd like to be able to use akka on all platforms avalonia supports (web, ios, android, mac, linux, windows, even embedded).
Is AOT possible at all right now? I'm learning F# with an avalonia side project and I'd like to be able to use akka on all platforms avalonia supports (web, ios, android, mac, linux, windows, even embedded).
For core Akka yes, so long as you don't use ReceiveActors - they're the biggest stumbling block. Them and the old System.ConfigurationManager bits.
Is your feature request related to a problem? Please describe.
Part of the goal for Akka.NET v1.6 is to be able to get Akka.NET to run everywhere:
One of the major advantages Akka.NET has over Orleans et al is our versatility - we're not dependent on external cloud infrastructure in order to run. Akka.NET's ability to run in a stand-alone .NET process with in-memory messaging is a tremendous source of value for developers. We should lean into this.
The future of .NET is to expand beyond Windows and even x64 architectures - Ahead-of-Time Compilation, "AOT," is what will open the door for Akka.NET to be able to run on an even larger number of platforms more efficiently than it can today. So for v1.6 we are putting "full AOT support" on the critical path.
Requirements
Where are the problem areas that prevent full AOT support today? My AOT canary implementation on TurboMqtt highlights some of the big ones: petabridge/TurboMqtt#25
System.ConfigurationManager
#7430Type
loading for default implementations #7431ReceiveActor
,Props
, and more: see System.Linq.Expressions - Excessive allocation and prevents AOT scenarios #2811 and other related issuesSystem.Object
serialization - we are already planning on moving to Roslyn Source-Generator powered serialization in v1.6, which should address this issue.Props
and its use ofNewExpression
- this is a no-no. We might need to go to more basicFunc<TActor>
implementations or other ways of specifyingProps
without using aNewExpression
. Worth noting:NewExpression
has been a source of perf issues as well.All of these will need to be addressed, gradually, by leveraging tools like the
Setup
class (replaces HOCON-drivenType
loading with static-linking-friendly loading) and changing the way some of Akka.NET's built-in components attempt to load configuration.Things Users Need to Do To Prepare for AOT
If you care about AOT, please read the next sentences carefully:
ActorSystem.Create
experience, with no custom plugins / Akka.Remote / Akka.Cluster / Akka.Persistence et al, will be automatically AOT-friendly out of the box;If you have any other thoughts or suggestions when it comes to AOT support, please leave them here.
The text was updated successfully, but these errors were encountered: