I’d be interested in a comparison with Lunatic, which is a custom runtime for Wasm (and therefore Rust) which also does pre-emptive scheduling, something Ractor can’t do (and the BEAM does)
…makes local actors available on a remote system by spawning RemoteActors which are essentially untyped actors that only handle serialized messages, leaving message deserialization up to the originating system.
Oh, that’s pretty interesting. Safe serialization/deserialization to a shared data model always seems to be one of the tricky bits of distributed systems, since said data model always seems to either be viciously language-specific, or become an API boundary of its own that requires management, or both. I think one of the unsung successes of RDBMS’s is they create a shared data model that their clients need to understand, and it’s a pretty useful one.
It looks like ractor doesn’t necessarily define the serialization method for you, which is a pretty interesting choice: it just requires your messages to implement the ractor::BytesConvertable, which you can derive or implement on your own types however you want. However, if your messages are defined using protobuf then there’s some macros to help with it, and it uses protobuf for its own internal messaging protocol.
More than iron, more than lead, more than gold I need electricity.
I need it more than I need lamb or pork or lettuce or cucumber.
I need it for my dreams.
(This is tangentially relevant, but maybe only for us older folks…)
I’d be interested in seeing comparisons to Bastion, what their relative strengths are.
I’d be interested in a comparison with Lunatic, which is a custom runtime for Wasm (and therefore Rust) which also does pre-emptive scheduling, something Ractor can’t do (and the BEAM does)
There’s some commentary from the author on the Hacker News thread. Ractor is used in production at WhatsApp.
Oh, that’s pretty interesting. Safe serialization/deserialization to a shared data model always seems to be one of the tricky bits of distributed systems, since said data model always seems to either be viciously language-specific, or become an API boundary of its own that requires management, or both. I think one of the unsung successes of RDBMS’s is they create a shared data model that their clients need to understand, and it’s a pretty useful one.
It looks like
ractordoesn’t necessarily define the serialization method for you, which is a pretty interesting choice: it just requires your messages to implement theractor::BytesConvertable, which you can derive or implement on your own types however you want. However, if your messages are defined using protobuf then there’s some macros to help with it, and it uses protobuf for its own internal messaging protocol.More than iron, more than lead, more than gold I need electricity. I need it more than I need lamb or pork or lettuce or cucumber. I need it for my dreams.
(This is tangentially relevant, but maybe only for us older folks…)
https://en.wikipedia.org/wiki/Racter for anyone, like me, who missed the reference.
That’s what we called ChatGPT in 1984 and we liked it that way!
RACTER! I was coming here to post something substantially similar.
Almost as if you were going to take some of the content and remix it slightly based on templates? narrows eyes
taps nose
Well that is an unfortunate naming collision.