tellus against kameo and ractor

Read this before drawing conclusions

1. tellus's receive is synchronous; kameo's and ractor's handlers are async fn. tellus therefore avoids allocating and polling a future per message, but cannot await inside receive. This is a capability difference, not only a speed difference, and it favours tellus on exactly these microbenchmarks.
2. tellus's mailbox is statically typed; the others erase message types, costing an allocation and a dynamic dispatch per message that tellus does not pay.
3. Competitors are configured for speed, not defaults. kameo runs without tracing and ractor without message_span_propogation, both of which add per-message instrumentation that tellus has no equivalent of. This biases the setup in the competitors' favour.
4. Messaging microbenchmarks only. Nothing here speaks to supervision, distribution, ergonomics, memory use or production readiness. kameo and ractor are mature, feature-rich frameworks; tellus is under active development and does far less.
5. On CI these run on a shared 2-core runner, so absolute figures are not representative of real deployments. Only the relative comparison within a single run is meaningful.
6. Written and run by tellus's maintainer. The full methodology and benchmark source are in the repository; corrections are welcome.