Our great sponsors
-
ponyc
Pony is an open-source, actor-model, capabilities-secure, high performance programming language
-
differential-datalog
An in-memory incremental Datalog engine based on Differential Dataflow (by Kixiron)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
tokio
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Pony actors are also using mpsc channels/messaging while switching on the message as well. Channels themselves aren't slow, its how they're used instead. Pony sends what code needs to be executed on the actor memory instead of sending the memory around as popularized by things like Go and many async rust libraries. This is also a common idiom seen elsewhere and it helps in making the program more resource efficient.
While your observations may be insightful, they only represent crossbeam, not the [MS]P[MS]C abstraction itself. Crossbeam being a well regarded crate doesn't necessarily mean its well optimized, scalable, or efficient/correct. While a good faith assumption, these internal inefficiencies are a common trend across well-known crates. Because of this, and the wide statement, I don't believe your statement should still stand.
There are loads of mutex implementations, each with varying throughput characteristics.
Again, the community recognizing an algorithm as such doesn't inherently make it sound or race-free. Its easy to write something that isn't, sure, but thats not the point because its also easy to write something that is when you have enough experience and time.
This is a logical fallacy. Specifically either a "Slippery Slope" or "Either/Or". You assume that fast channel implementations must have originated or have been ported to Rust and are both popular. Things like Stakker and zap are anecdotal examples of where this already isn't the case. Even so, there exists fast synchronized channels both inside and outside of async Rust. Because they aren't popular or aren't tuned to efficient runtimes doesn't mean they don't exist, which was my argument.