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

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

github.com

174 pointsibraheemdev41 comments

This is one of those projects where there are lots of great words, but honestly, a simple code example would speak a thousand more in terms of helping people understand what's possible and how it works.

I read through this and their documentation and literally have no idea what this feels like to the developer or how to start.

The readme links to a getting started example [0], an example directory [1], and their website has a couple of examples as well [2].

0: https://github.com/bastion-rs/bastion/blob/master/src/bastio...

1: https://github.com/bastion-rs/bastion/tree/master/src/bastio...

2: https://bastion.rs/

Great - if you are a contributor, I'd recommend hoisting that HelloWorld example up to the home github page and talking the arriving new user through it.

I have a hard time framing what this does exactly even with the examples and need subtitles. :)

Politely :) I would like to know your experience level with distributed F/T systems. I ask because they are not just throwing around buzz words: they are being quite precise with defining their platform. I skimmed that readme and it was quite clear, and in fact 'Bastion Executor' bit aroused a bit of Rust envy.

Some follow up questions for me would be around the messaging guarantee (AMO) and what sort of effort is required to, say, implement OTP semantics in Bastion.

Here is Erlang OTP's doc with code snippets for your comparative reference:

https://erlang.org/doc/design_principles/des_princ.html

Probably clear I don’t have a lot of experience! :)

But maybe I should? Maybe that example would help? :)

You definitely should learn - it's a lovely domain for geeking out -- but you first need to acquaint yourself with the technical domain. I honestly don't see how an example would get you from 0 to nodes up and running with understanding.

Here are two good starting points (since Bastion is the same type of platform): https://learnyousomeerlang.com/what-is-otp

https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...

That first link has what you want: examples. But note how many pieces are involved and that it is not a 5 minute read :)

Top level, a project like this needs to communicate to the intended audiance -- here, people who are building F/T distributed actor systems -- what the project brings to the table, and imo they did a good job in that regard.

Good points. In the mean time you can read what Akka and Erlang are. They are both actor based systems. From a quick glance that is what Bastion is as well.

Previous discussion: https://news.ycombinator.com/item?id=22403713

"If you want the smell of Erlang and the powerful aspects of Rust"

Example:

  use bastion::prelude::\*;

  #[fort::root]
  async fn main(_: BastionContext) -> Result<(), ()> {
      println!("Running in Bastion runtime!");
      Ok(())
  }

Nice talk on the simple and powerful error handling philosophy enabled by this approach:

Crash Course with Bastion— Mahmut Bulut https://www.youtube.com/watch?v=IsBNjJBlA1E

Seems very interesting. Seems like doing Erlang OTP in Rust. But this is one of those projects where a simple tutorial would be super helpful. WhatsApp is famously written in Erlang. Perhaps, a simple tutorial of building a distributed chat backend using this library/system would help a lot of people see how this would be used.

How does Bastion compare with https://riker.rs/ and https://actix.rs/ ?

edit: good reads https://www.reddit.com/r/rust/comments/flf2ld/how_does_rusts...

past discussion: https://news.ycombinator.com/item?id=22403713

I've read the readme, and still not entirely clear. I know it's not a 1:1 analogy but it this effectively a distributed task queue?

It looks like an Erlang-inspired Actor system, but I've never had any experience with this type of programming model, so I don't know what its benefits are.

It'd be nice to have a few code snippets geared at newbies in the README as well as a pointer to blog posts explaining why actor-based systems are great.

I want to investigate this, but I don't have the time to research any of this right now, and none of that information is right in front of me.

Can someone explain what "proactive I/O is?"

Some googling makes me think it's just asynchronous I/O with an explicit continuation, but I might be wrong.

That's interesting.

I am going to reason about this. It's me thinking aloud here.

I already know that JS callbacks and promises are somewhat equivalent to continuations. A continuation is something which is to be done later and which is passed as a value to functions which then directly or indirectly invoke the continuation or not if it is decided not to do the thing encapsulated in the continuation (for example if something failed and the algorithm is trying to bail out such that it doesn't make sense to continue with the continuation).

I also know that JS async/await is equivalent to generators. Koa version 1 used generators and Koa 2 switched to async/await.

I also know that Rust futures are or were based on generators. Rust generators are not stable and the last time I looked they were a bit left behind by futures. For me it seems that futures rely on some compiler magic such that they work even if generators are not stable.

Therefore Rust futures are somewhat equivalent to continuations.

There's a difference as far as I know, however. Continuations seem to be strictly more powerful than generators. In other words, you can implement generators by continuations but not the other way around.

Sorry, I made an ambiguous comment. I meant continuation as in "continuation passing style" not as in "first class continuation"

It looks like the proactive IO in Bastion is using Rust's async/await, which I know nothing about, but in most languages async/await exists as sugar to make CPS look like linear flow.

I think it's in contrast to "reactive IO".

Roughly:

When you want to read from files reactively, you run "select" with these files as arguments in a loop. The return value will tell you, which file is ready to be read.

In proactive IO, you instead supply a buffer to the read operation and get a handle back, that will notify you when the read operation is finished. Windows IO Completion Ports (IOCPs) are an example of this.

I can already imagine some HR people/recruiters going “why is this guy listing a game in his résumé?”

Bastion or Rust?

Mostly Bastion. I believe that the popularity ratio of Bastion game/Bastion tech is much greater than Rust game/Rust tech.

(I almost can’t believe I just made this metric up.)

It’s a well known metric, as of this moment. Popularity ratio = (Total sales) / (Number of GitHub stars of the project).

Bastion ratio = (3 million/1953) = 1500

Rust ratio = (9 million/52700) = 180

Bastion sales source (2015) -https://www.supergiantgames.com/blog/transistor-earns-60-ind...

Rust sales source (2019) - https://facepunch.com/news/2019

The metric isn’t perfect. It should probably decay the popularity of older games and unmaintained repos.

Both.

1. https://store.steampowered.com/app/107100/Bastion/ 2. https://store.steampowered.com/agecheck/app/252490/

Is everybody using 500ppi screens or is the logo ridiculously big?

This sounds cool. I don't understand why it's named Bastion though, that name already has pretty specific technical meaning to me which seems unrelated.

Bastion means "a well-fortified position." I think this is meant to highlight the fault-toleranceness of the runtime.

But if it's an Erlang-style system, it gets its resilience by acting less like a solid fortress and more like a guerilla force that melts away when you attack it. :D So I'd still have to say Bastion is an odd name.

Reply on news.ycombinator.com