Fiahil

Oh, you should try OpenSpec !

Not Op.

For 1), yes, there is an "observe" step in the process where - when the project is deployed - it observes and reconciles what happens vs what should happen based on specs.

I believe more variant are bound to emerge when harnesses become more prevalent. We only scratched the surface, so don't generalize over the process yet.

Clasp, from Foundation, was nice

Question to the one that tested it : Does it still timeout a lot with unreliable response time (1-5 sec) ?

At some point, the community is also responsible for the demanding expectation of a "not slow" compiler.

What's "slow"? What's "fast"? It depends. It depends on the program, the programmer, his or her hardware, the day of the week, the hour of the day, the season, what he or she had for lunch, ...

It's a never ending quest.

I, for exemple, am perfectly happy with the current benchmark of the rust compiler. I find a x2 improvement absolutly excellent.

You can go one step further if :

- you don't reallocate the array

- you don't allow updating/ removing past inserted values

In essence it become a log, a Vec<OnceCell<T>> or a Vec<UnsafeCell<Option<T>>>. Works well, but only for a bounded array. So applications like messaging, or inter-thread communication are not a perfect fit.

It's a fixed-size vector that can be read at the same time it's being written to. It's no a common need.

Yes, but that’s only a few hours away through hyperspace !

I think you misread :

- 2 actors on 1 thread = OK

- 1 actor on 2 thread = you are probably doing it wrong.

As for the rest, whether or not they are used in communication systems and whether or not they are cpu-bound, consider there are and run the handle on a separate loop from the main message dispatching. Otherwise you _will_ delay messaging if handles don't await.

> multiple actors can run on a single thread.

Right. It's not a very widespread use case, to be honest. You'd find that most would be N actors for M threads (where N <= M ; an Actor in itself is never shared among multiple threads [So `Send` and not `Sync`, in theory] - an inner message handler _could_ have parallel processing but that's up to the user)

I think you should assume in Kameo that every Actor's message handler is going to be CPU-bound. For example, it means that your internal message dispatch and Actor management should be on a separate loop from the User's `async fn handle`. I don't know if it's already the case, but it's an important consideration for your design.

Nice library, BTW, I think it checks all the marks and I like your design. I've tried most of them but could not find one that I liked and/or that would not have a fatal design flaw (like async_traits, ...) :)

PS : Multi-threaded tokio runtime should be the default. Nobody wants a single-threaded actor runtime. It should be in capital letters in the readme.

What's the reason for using Async for an Actor framework ?

They run in separate tasks / threads anyway and they are cpu-bound. So, why would it be necessary to make them async ?

Can I mix french and english when talking to it ?

stomata open, light interacts with chlorophyll, water is moved and creates a tiny depression in the xylem tube, more water moves up through capillarity