Questions about the library

[sezaru]

Hey, I hope you don't mind, but I created this issue ticket to ask some questions about your library since I couldn't find another way to contact you.

First things first, congratulations on this library, I am really amazed at how well you translated the actor model to Dart. Really great job!

Now, for my questions:

• In your opinion, how production-ready do you think your library is? I know there are beta parts like remote messages, etc. But thinking about the core functionality (actors, supervision, fault-tolerant, and message passing) do you think it can be safely used?
• Is the intent of this library also used for mobile development (Flutter)? I was thinking that using the actor model to instantiate services used by a mobile app would be a great approach, is this one of the intended purposes or do you see some limitations when using this library for mobile apps?
• Are you planning to maintain this project in the long term?

Thanks again for the library!

[GlebBatykov]

Hi!

As far as my library is ready for production? I believe that the main functionality of the library is ready. But I do not deny that errors may probably be detected. I received almost no bug reports and tested it exclusively myself.

I do not recommend using remote interaction tools in production yet. This functionality has not been tested enough yet. But in the next update I plan (I have already developed this functionality) to add a lot more tools for remote interaction. For example, it is an opportunity to get a list of addresses of existing actors from a remote actor system. The ability to receive notifications in the actor when a connection to a remote actor system has occurred. Initiate a connection to a remote actor system during operation, and not just configure it when starting the actor system.

Is it possible to use this library in Flutter. Yes, you can. Initially, I was focused on the server side, but I assumed that the library could be used in mobile applications. Except that it may be somewhat redundant (there are rarely tasks where it really turns out to reveal the benefits of using a large number of isolates and building interaction between them).

There is only one disadvantage of using my library in Flutter, it is that it is impossible to use Platform Channels in actors. But I was considering options on how to make this possible. In short, I would need to write platform code for all platforms that would be responsible for creating an isolate, running the Flutter engine in it. And then, as far as I understand, Platform Channels would work inside the isolates in the actors.

[GlebBatykov]

I try not to introduce critical changes in updates. Which also affects the use of the library in production. But there will be several such changes in the next big update.

[GlebBatykov]

About supporting the project in the long term. It depends on whether people will use it. I like doing this project, but I got the feeling that the actor model is not particularly interested in the Dart community.

[sezaru]

Except that it may be somewhat redundant (there are rarely tasks where it really turns out to reveal the benefits of using a large number of isolates and building interaction between them).

So, in my case, my interest in this library for mobile is in other aspects of the actor model, one is fault-tolerant and another one is state management.

For the fault-tolerant part, I find your library interesting because it implements the notion of supervisors, so what I can do is add all my initialization code for my app inside actors and in a supervision tree, that way I can make sure my system is initialized correctly and all the parts will restart themselves correctly if a crash occurs.

The other aspect is state management, but to need that the message processing should be sequential, which is what we were talking about in the other tickets anyway. This allows me to always have a correct state to give to interested callers.

Ex. Imagine that I have two parts of the system checking a subscription, they both first get the subscription from an API call, and depending on some condition, they change the subscription. If I don't make that call sequential I can have a race condition, since both callers can first call the get API, and then both will have the condition to change the subscription creating an undefined behavior.

I know that Dart is single-thread and this is very hard to happen, but there are some cases for that, hence why libraries like https://pub.dev/packages/synchronized exist.

Encapsulating that in an actor that handles messages sequentially, solves the problem in a neat way IMO.

Finally, you are correct regarding platform channels, currently, that would be a limitation that would not allow me to use this library since most of the code I want to initialize uses platform code.

Maybe a good alternative to this is having an adapter for the direct isolate methods? I mean, there are already some libraries that solve this specific problem, so if there was some easy way to replace the native isolate dart methods with the library one, I think I would be able to use that one and have platform channels for free. Do you think something like that would be possible?

[GlebBatykov]

I'll think about making 2 versions of the package, the usual one, with the usual initialization of isolates.

As well as the version for Flutter. I may be able to use the flutter_isolate package for this.