Actors for other languages #68
Replies: 2 comments
-
Thanks for the discussion and I think it's a very interesting topic! You could probably write wrappers in each language that extend the primitives we're providing here, but I can imagine it'd get a little harry with things like message types. Structs probably won't map amazingly without using like a serialization format (protobuf, json, etc). I'm also not clear how RPCs would work, but I think in theory it's possible. I'd say start with a simple single language, which has a lot of functionality and libraries to support (e.g. python or something) and go from there. The other option is C++ with CXX which is worth mentioning, since it's 0 or near-0 overhead. |
Beta Was this translation helpful? Give feedback.
-
Agree, it would be quite problematic to develop actors in other languages. However, it is quite easy to create wrappers around Ractor Actors implemented in Rust. Here is a Python example: https://github.com/cjuko/ractor-pyo3-example. |
Beta Was this translation helpful? Give feedback.
-
Hello, this crate looks great for my use case and is something I've been thinking about for a while. Great work!
I'm not sure if you've seen Lunatic, which comes from similar Erlang inspirations: https://github.com/lunatic-solutions/lunatic
Personally, I prefer ractor's implementation as I'd rather avoid the limitations that come with WebAssembly. However, the ability to use other languages that compile to WASM does appeal to me. Which lead me to think about how this could be implemented in ractor.
Basically, most scripting languages have decent enough interop crates:
My intention would be to write ready made Actors for each, such that you could utilise ractor's orchestration features and run Ruby/Python/Lua/JS tasks. You lose some of the sandbox benefits of WASM, but you gain the full capabilities of each language with no restraints on libraries you can use. There would be obvious orchestration challenges, but in theory I think this would be possible.
The main benifit of this is that as developers you can often move faster by developing in a more dynamic language like Ruby, with Rust being the end-goal for compute heavy functionality. This is very similar to how Discord use Elixir and Rust, using NIFs to carry out heavy compute tasks. Interestingly, Elixir's syntax is heavily inspired by Ruby, so perhaps it's coincidental that ractor could be used to orchestrate Ruby Actors (i.e. it's basically Elixir without the functional paradigms).
It'd be great to hear your thoughts on this @slawlor. It's essentially BEAM and OTP for many languages, without limitations (TBC).
Beta Was this translation helpful? Give feedback.
All reactions