3 ms·

Nice article. Any project rewritten from scratch (version 3 here) by the same experienced engineers will inevitably be better/more robust/more performant than t

Nice article. Any project rewritten from scratch (version 3 here) by the same experienced engineers will inevitably be better/more robust/more performant than the previous versions. During our career growth as craftsmen, we build using tools we understand, and get a certain output. As we learn more about various other tools (techniques), we have a wider understanding and will make it better again. Having read about their journey, I can see they use 77 mutexes and a hierarchy chart for locking to prevent deadlocks. How quaint. I keep on harping about the Actor programming model to deaf ears, but I guess the apprentices need more stumbling around before achieving true enlightenment. Version #4, perhaps? Any guru want to share what path to take after Actors? I’m ready…

kriiuuu 2y ago
Effect systems are great for concurrent programming and easier to reason about than actors. They aren’t available in all programming languages however.
znkr 2y ago
Not a guru, but my take is that the actor model is one method of architecting a system to separate synchronization from other concerns. There are other ways to do that, often specific to a particular problem and with more or less separation. As always, there are many tradeoffs involved.
mrkeen 2y ago
After actors? Transactions for sure. The SQL databases have been doing it the right way for just as long.
Sytten 2y ago
The problem with actor in rust is two fold and would prevent their use in this context I think: - They need async. Otherwise you need to implement yielding in house, have one actor per thread, etc. OS code is usually sync / callback based. - They need owned and usually send for all input. Since you have to send input / messages over a channel it makes it a requirement to have owned values and send if crossing thread boundaries. Very annoying requirement in rust.

kriiuuu 2y ago

Effect systems are great for concurrent programming and easier to reason about than actors. They aren’t available in all programming languages however.

znkr 2y ago

Not a guru, but my take is that the actor model is one method of architecting a system to separate synchronization from other concerns. There are other ways to do that, often specific to a particular problem and with more or less separation. As always, there are many tradeoffs involved.

mrkeen 2y ago

After actors? Transactions for sure. The SQL databases have been doing it the right way for just as long.

Sytten 2y ago

The problem with actor in rust is two fold and would prevent their use in this context I think: - They need async. Otherwise you need to implement yielding in house, have one actor per thread, etc. OS code is usually sync / callback based. - They need owned and usually send for all input. Since you have to send input / messages over a channel it makes it a requirement to have owned values and send if crossing thread boundaries. Very annoying requirement in rust.