[HN Gopher] Show HN: Kameo - Fault-tolerant async actors built o...
___________________________________________________________________
Show HN: Kameo - Fault-tolerant async actors built on Tokio
Hi HN, I'm excited to share Kameo, a lightweight Rust library that
helps you build fault-tolerant, distributed, and asynchronous
actors. If you're working on distributed systems, microservices, or
real-time applications, Kameo offers a simple yet powerful API for
handling concurrency, panic recovery, and remote messaging between
nodes. Key Features: - Async Rust: Each actor runs as a separate
Tokio task, making concurrency management simple. - Remote
Messaging: Seamlessly send messages to actors across different
nodes. - Supervision and Fault Tolerance: Create self-healing
systems with actor hierarchies. - Backpressure Support: Supports
bounded and unbounded mpsc messaging. I built Kameo because I
wanted a more intuitive, scalable solution for distributed Rust
applications. I'd love feedback from the HN community and
contributions from anyone interested in Rust and actor-based
systems. Check out the project on GitHub:
https://github.com/tqwewe/kameo Looking forward to hearing your
thoughts!
Author : tqwewe
Score : 57 points
Date : 2024-10-02 18:22 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| __erik wrote:
| This looks really nice! Curious if its running in production
| anywhere
| qwertox wrote:
| I agree, really nice syntax.
|
| There's a limitation mentioned in the docs:
| While messages are processed sequentially within a single
| actor, Kameo allows for concurrent processing across multiple
| actors.
|
| which is justified via This [sequential
| processing] model also ensures that messages are processed in
| the order they are received, which can be critical for
| maintaining consistency and correctness in certain
| applications.
|
| I agree to this and it gives the library a well defined use.
|
| Docs and examples are well made.
| m00x wrote:
| What are the advantages and disadvantages vs using Actix or
| Ractor?
| TheMagicHorsey wrote:
| Looks really nice.
|
| But sometimes when I see projects like this in other languages, I
| think, are you sure you don't want to use Erlang or something
| else on the BEAM runtime and just call Rust or C via their NIFs?
|
| I used Erlang about a decade ago, and even then it was so robust,
| easy to use, and mature. Granted you have to offload anything
| performance-sensitive to native functions but the interface was
| straightforward.
|
| In the Erlang community back then there were always legends about
| how Whatsapp had only 10 people and 40 servers to serve 1 Billion
| customers. Probably an exaggeration, but I could totally see it
| being true. That's how well thought out and robust it was.
|
| Having said all that, I don't mean to diminish your
| accomplishment here. This is very cool!
| greenavocado wrote:
| Massive context switching and type checking on Erlang is
| inferior.
| hansonkd wrote:
| I think a lot of issues BEAM was trying to solve were solved by
| processors getting bigger and more cores.
|
| BEAM's benefit 10-20 years ago where that inter-node
| communication was essentially the same as communicating in the
| same process. Meaning i could talk to an actor on a different
| machine the same way as if it was in the same process.
|
| These days people just spin up more cores on one machine.
| Getting good performance out of multi-node erlang is a
| challenge and only really works if you can host all the servers
| on one rack to simulate a multi-core machine. The built in
| distributed part of erlang doesn't work so well in modern VPS /
| AWS setup, although some try.
| throwawaymaths wrote:
| Is this actually distributed? I see no evidence that this can be
| used in conjunction with even ipc with builtin features.
| hansonkd wrote:
| Check the examples folder.
| qwertox wrote:
| https://github.com/tqwewe/kameo/blob/main/examples/remote.rs
| // Bootstrap the actor swarm if is_host {
| ActorSwarm::bootstrap()?
| .listen_on("/ip4/0.0.0.0/udp/8020/quic-v1".parse()?)
| .await?; } else {
| ActorSwarm::bootstrap()?.dial(
| DialOpts::unknown_peer_id()
| .address("/ip4/0.0.0.0/udp/8020/quic-v1".parse()?)
| .build(), ); } let
| remote_actor_ref =
| RemoteActorRef::<MyActor>::lookup("my_actor").await?;
| match remote_actor_ref {
| Some(remote_actor_ref) => { let count =
| remote_actor_ref.ask(&Inc { amount: 10 }).send().await?;
| println!("Incremented! Count is {count}"); }
| ...
| throwawaymaths wrote:
| Thanks! It's not in the front page material.
| BWStearns wrote:
| Looks very cool. Is there any documentation on how it works for
| communication over a network? I see the remote/swarm section but
| is there an overview somewhere?
| fuddle wrote:
| Looks good, it would be great to see more examples in the docs.
| wildlogic wrote:
| Hi - any documentation regarding actor registration? Is there a
| conventional way to inform a remote actor about a new actor?
| Would this be sent in a message? How does the
| actor.register('name') work? Maybe could be a useful addition to
| the documentation. Thanks.
___________________________________________________________________
(page generated 2024-10-02 23:00 UTC)