Bastion – Highly-Available Distributed Fault-Tolerant Runtime for Rust | Hacker News Reader

Bastion – Highly-Available Distributed Fault-Tolerant Runtime for Rust

github.com

This is interesting.

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 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.

Seems to have been abandoned almost a year ago. Their Discord server also has no activity.

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.

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.

Please don't raise facile, generic objections.

And what makes you think Bastion falls under this category?

Taking a cursory look at their example, and this caught my eye:

    supervisor
      .broadcast("A message containing data.")
      .expect("Couldn't broadcast the message.");

As a non-native English speaker, the word expect tricks me up here. Is this use correct?

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.

[1] https://doc.rust-lang.org/std/option/enum.Option.html#recomm...

That's standard Rust error-handling code: it prints an error message and panics out (if I remember correctly, I haven't touched Rust in years).

"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

; @ D

expect() is an assertion of non-failure. The string is the panic message on failure.

Is this comparable to BEAM for erlang/elixir but for rusticians?

Reply on news.ycombinator.com