Result of this discussion 
I sadly don’t have a lot of time but I’d just create a few threads and send them messages through a channel. Is that what you did originally?
Thanks you for said about
Rust optimization flags ,
That very helped to me .
What i wanted is this .
A framework/language for real-world
project with good productivity ,
Rust Tokio + Tonic is great for that i want.
but Beam giving to me Mnesia
( Distributed real time database )
That is exactly i want ( I have a idea for my app and that need read-heavy Search query ( fetch from table with some condition over fields ) very fast ( near real time )
After research find some solution like
Apache Ignite , and Couchbase and Tarantool.
But i want open source solution,
Apache ignite was great but have driver for some language/technology those are not my favorite.
I have two way :
-
Write a Distributed, Replication Database over
Sqlite engine with Rest API in Rust . -
Choose Erlang/Elixir with Easy life because
solved my problem before
1 way is not hard because, i did thinking and designing it near 2 month .
- Way is good because i work with deep features of mnesia for a distributed project before, and i have good control over it.
if you have a suggest for my road very thank you if said 
Be careful with mnesia, it is not necessarily the easiest thing to use in real world scenarios. Its handling of netsplits is pretty iffy, and there are challenges you can run into if you are regularly adding or removing nodes during deployment (eg, rolling deployment).
The BEAM is absolutely awesome at message passing, but any use of mnesia needs to be done very carefully and with serious testing of its edge cases.
3 Likes
I have no idea how you draw that conclusion when, by your own numbers,
SINGLE threaded Rust beat MULTI-threaded Beam
If anything, it proves the benchmark is artificial.
1 Like
I don’t know if khepri might be worth looking into over mnesia and I’m sure I heard the sqlite guy on a podcast recently talking about distributed sqlite. So you might not have to implement it yourself. But you might have to pay 
to hardly understand your mean. But if you do discussion instead of fighting , we can get our answer.
And they aren’t my numbers ,
They are result of machine
Thank you for link.
I im ok for writing and thinking more instead of paying more , i have enough exprience and science for writing good infrastructure 
You wrote a benchmark where:
- multi-threaded Beam beats multi-threaded Rust
- single-threaded Rust beats both { multi-threaded Rust and multi-threaded Beam}
======
The conclusion you claim from this is ‘multi threaded beam beats multi-threaded Rust’.
An alternative conclusion is – because of (2), that this benchmark is pathological – and whatever it measures it’s not multi threaded performance.
I agree with you here, the benchmark is pretty artificial and I’m still not sure what it’s supposed to prove.
Go low-level enough and you’ll eventually only be measuring different ring-buffer-like structure performance in the kernel, right? (The stuff that channels and queues are often based on)
IMO such benchmarks have to have a specific goal, otherwise they’re just turning into flexing.
Example: if you need to read several million records from a file and insert them in a DB then picking a system language is fruitless and it will mostly get in your way. With Elixir you’re like 10 coding lines away from having parallel code that splits the records in chunks and do DB insert of each chunk in an actual separate OS thread. I’ve done such workflows many times and Elixir’s overhead compared to C or Rust is like 1-2% of the run time (since most of it is waiting on I/O anyway). But you do it in 10 lines whereas with C or Rust you might tear your hair out until you code this rather simple use case.
I love Rust and will be getting better at it but let’s use programming languages to their strengths.
So parallel message passing? I’m 100% sure an expert Rust programmer can devise code that will put Elixir to shame – question is, does it have to? If you ingest tens of thousands of financial events per second the answer is yes. In many other cases the answer is no.
Yes i agreed, i just wanted said rust community said, solution for this is switch to single thread,
but beam is more optimized in multi thread message passing.
My focus was message passing else even junior developer know rust is one of fastest , and i love it .
You said expert rust progammer !!
I sended this rust codes to Alice , she is
one of maintance Tokio developer,
She said two way for this ,
First was parallel call and await on all responses
(Actually this was not good comparing because in Elixir i use genserver call and it block process untill get response or timeout )
Second was using Single-thread Scheduler.
Actually we not want prove which always run faster , we just want see Beam how much is fast and forget stress of speed
now, I know Beam is very fast
Glad I took the time to discuss this, I learned good things, thank you all guys 
