What do you mean by abandoned? Do you think a project died the moment someone stopped changing it? Believe it or not, sometimes stuff work sell enough.
Yes, if a project is not in a fully-field-tested, fully stable state, but commits to it have ceased and the last messages in its dev channel are from many months ago, the project is abandoned.
I wasn't able to find any projects that actually used bastion, which is too bad. I'm very curious about "fault tolerance" and how it could complement Rust.
I wrote a multithreaded actor implementation in Java without locks that can reach throughputs of 19 million assuming a batch size of 10 messages at a time.
I am curious what a Rust message passing implementation throughputs would scale to given that it is a multithreaded problem and there's cost to synchronization. Synchronization is expensive.
I have a vague understanding of actors and fault tolerance, but it's not clear to me if actors provide fault tolerance or if they just make concurrent programming less error prone? Would be happy for someone to stream-of-consciousness riff about how an Erlang-like fault tolerant approach to reliability compares with a more traditional approach in theory and in practice. E.g., if you have a component that is just erroring and restarting all the time, how does the operator know that something is wrong? Do you have special monitoring? Do you look for restarts in the logs? I guess maybe what I want to know is "how does operating an erlang-ish service compare to operating a traditional service?"
If my actor crashes and the message hasn't been written to a write ahead log, the message would be lost since it's not easy to resume the processing of the message received without persisting it somewhere.
I am not that familiar with Erlang's supervision hierarchies.
You could do something similar to ActiveMQ and rebroadcast a message until it is acknowledged.
"I found Rust when no one heard of them, man. They really knew how to put on a show back then. Now, they're so mainstream and commercial, I'm over 'em. Their latest album is so pop. I heard from their managers that brainfuck and Zig are touring this year." <- Hipsters on music
I think the recommendation is to phrase the error message that is given to .expect() not as what went wrong but as what we had expected to happen.[1] If the example that you show was consistent with that recommendation, it might look like this:
supervisor
.broadcast("A message containing data.")
.expect("message broadcast should not fail");
Although even if you are a native English speaker, this is dubious improvement if you don’t know what Option types are and what .expect() does with them.
14 comments
[ 17.3 ms ] story [ 385 ms ] threadPlease don't raise facile, generic objections.
I wrote a multithreaded actor implementation in Java without locks that can reach throughputs of 19 million assuming a batch size of 10 messages at a time.
I am curious what a Rust message passing implementation throughputs would scale to given that it is a multithreaded problem and there's cost to synchronization. Synchronization is expensive.
https://github.com/samsquire/multiversion-concurrency-contro...
I am not that familiar with Erlang's supervision hierarchies.
You could do something similar to ActiveMQ and rebroadcast a message until it is acknowledged.
; @ D
[1] https://doc.rust-lang.org/std/option/enum.Option.html#recomm...