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 ?

Yet, legal opinions seems to differ : https://news.ycombinator.com/item?id=40423224

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

How does this compare to ZeroMQ (ZMQ) ?

https://zeromq.org/

The alternative is to dive into the literature on lock-free mpmc queues, which are kind of gnarly to implement. A lot of the literature handwaves ABA problems with stuff like "use hazard pointers and RCU" without correct pseudo code to help you.

Yes and I do think they are fundamentally incorrect or they cannot be translated to the log use case.

I also agree that, performance-wise, the lock make little difference. In fact my old benchmarks tend to point that locks were MORE EFFICIENT than atomics on ARM64 (MBP M1), for example. It's more like a fun little exercise, and also to confirm that I'm not completely dumb and that the problem is not solvable with the simple use of 2 atomics and a counter.

For the (un)bounded logs, the whole concept reside on the fact that the log isn't going to move once allocated, and that references to an item will never be invalided until the end of the program

in the case of a bounded log, readers are expected to give an offset at which they want to perfom the read (kafka-like).

So the linked list would involve going through all the links and following end tail refs/pointers. It would make reading O(n) and that's a Nope.

However, you could imagine having a Vec index that contains a ref to all allocated inner-logs, and query the index first in order to obtain the buffers' location. That works, but then the index has to go through a lock (either a RWLock or a mutex) as the CaS operation isn't enough if we get to the end of the index and it needs to be reallocated. It's fine, and I think that's the most appropriate solution.

PS : In fact, there is a sweet spot where you'd like to have a semi-unbounded log. If your index is big enough to contain something like 4Md entries, you'd probably end-up splitting the log in several pieces for archiving and performances purposes. Loading the log (fully or partially) from disk efficiently is then more important than having a real unbounded log. Then you would not necessarily use a lock and could CaS in the index.

I used the same approach while designing a lock-free bounded broadcast log (as in a "RWLock<Vec<T>>"; a MCMP, append-only Vec). It's quite easy to do because it's bounded. However, I could not find a way to make it both unbounded and efficient.

Any ideas ?

I'm a 5y user of Firefly-III, and was very happy with it. Unfortunately, JC5, I discovered Actual recently.

It's not that FIII is bad at was it was doing, but simply Actual was a bit faster, a bit simpler, a bit more practical to use when importing. I'm mostly using rules, categories and reporting.

No it's not, it's extremely common.

Arc-Mutex yes, Arc-Box no.

It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html

The type Arc<T> provides shared ownership of a value of type T, allocated in the heap.

Moreover, you don't even need the box for a dyn : https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3...

after the number of times I resorted to things like Arc<Box<..>>.

... What are you doing ? It's definitively unusual.

A Zoe is 1.5t ..

It also excludes the Toyota Prius and a few other hybrid because they weight more than 1.6t, despite not being an SUV.

FYI, a Zoe weights 1.5t

Question to my fellow Scandinavians friends (Hi! from France) :

In this matter, the union agreement is more or less what we call a "convention collective" in France ?

From my understanding of your description, "Tarifvertrag", is more like a "convention collective" in France.

If that's the case, then Tesla would have been subject to the CC as well, regardless of the unionised status of the employees.

You're launched high into the atmosphere! The apex of your trajectory just barely reaches the surface of a large island floating in the sky.

I got some serious Zelda: Tear of the Kingdom vibe reading this !

I don't think it's working properly. Most (if not all?) trains are going at around 40-20 km/h. Why would they all stop in the middle of nowhere like this ?

The answer is is the survey you linked : https://survey.stackoverflow.co/2022#technology-most-loved-d...

It's the most loved language, by a wide margin, and has been for several years.

PS: and to be honest, I love programming in Rust. So I will defend it tooth and nail even if I can't use it in my day-to-day work at the office.

To answer a query, your LLM needs to "read" the documents first. The context window will not be big enough for this, so you have to fine tune the model.

Problem is, you need to cross-check with the reference material in case it's subject to hallucinations.

See Also: Loom (https://github.com/tokio-rs/loom), a concurrency permutation testing tool.