Bastion – Highly-available distributed fault-tolerant runtime

by windor • 6 years ago

201 43 6 years ago

windor5• 6 years ago

Very appreciate the work on bastion, which really gets the spirit of erlang actor programming with the supervisor-ing strategy! The code is clean and well documented, and I cannot believe the project is not well-known by rust communities.

windor5• 6 years ago

BTW: They are working on Hot-Code Swap.

mkj• 6 years ago

This looks promising, though the "No Forced Trait Implementations" seems to instead require using a strange looking msg!() macro?

https://docs.rs/bastion/0.3.4/bastion/macro.msg.html

Seems less clean to read than Riker (https://riker.rs), though that doesn't really do async well.

windor5• 6 years ago

Yes, the msg!() macro is a little painful to write. I think it can be refactored into the pattern like `impl Handler<Msg>`. But beyond that, it supports async/await naturally. :)

jokoon• 6 years ago

I have hard time understanding what this is. Is an alternative to docker somehow? What other framework/platform would bastion compete with?

sheeshkebab• 6 years ago

It’s more like Nats.io - an async message server, just for rust

coenhyde• 6 years ago

So did it. I didn't know if it was a service or a library or if it integrates with something. Looks like it's a library for Rust. I think mentioning Rust would speed up the understanding of where this sits

windor5• 6 years ago

Yes. the title was changed which I wasn't aware of.

Origin title: `The missing part of actor-model programming in rust`.

windor5• 6 years ago

It's a library in rust for actor-model programming like erlang does.

kitd• 6 years ago

It provides a distributed actor runtime a la Erlang, but for Rust.

The Getting Started example gives some useful insights:

https://github.com/bastion-rs/bastion/blob/master/bastion/ex...

ronmex• 6 years ago

Looks like Akka Cluster for rust?

paulsutter• 6 years ago

Could we hear a little more about the background of the project, including what it's being developed for? Really interested to learn more about the project, this looks great

elteto2• 6 years ago

How is runtime fault-tolerance achieved? My understanding of Erlang is that the BEAM VM implements these capabilities (custom threads, supervision, restarts, hot reload), but it is one level removed and above actual code. And they implement their own user-space threading runtime in order to support them. But in Rust, there is no such runtime (or is Bastion implementing one?) and it seems like this is used as a library. I'm very curious.

I think another way to frame my question would be: which is the basic unit of parallel execution in Bastion? A thread? Or a separate process? There are mentions of lightweight processes and subprocesses in the README but it is rather vague what these are.

blattimwind2• 6 years ago

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

StreamBright• 6 years ago

If an Erlang process crash cannot crash the entire system while Bastion's concept of a process can then threading is important part of fault-tolerance, isn't it?

elteto2• 6 years ago

It definitely is not orthogonal. Suppose an OS thread goes into an infinite loop. How do you cleanly stop it (feel free to assume Linux/Windows/MacOS)?. In Erlang this is possible because of the custom threading implementation.

zzzcpan2• 6 years ago

By runtime fault-tolerance they probably just mean an ability to do programmable supervisors that can react to actors dying, nothing special. And it's not like you can do a lot from a user space process anyway, apart from catching signals and destroying a currently running actor that caused it.

ignoramous• 6 years ago

How is runtime fault-tolerance achieved?

An actor is:

1. A lightproc, which, per my understanding, are async-spawned threads returning (optional?) Futures [0].

2. A ProcHandle [1] that lets you define process-state (like pid), control process-exec (like cancel, suspend?), listen on progress of a given lightproc that is run by BastianExecutors [2], whilst the message passing / supervisor semantics is handled by Bastion [3].

https://akka.io/ on JVM would be a better comparison to this than BEAM's implementation of actors, I think.

[0] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[1] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[2] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[3] https://docs.rs/bastion/0.3.4/bastion/struct.Bastion.html

spurdoman77• 6 years ago

Can someone elaborate use cases for this?

sbarre• 6 years ago

There's a whole section in the repo for examples and use-cases

https://github.com/bastion-rs/bastion/tree/master/bastion/ex...

hopia3• 6 years ago

Not knowing anything about Rust, I would imagine similar as those of Erlang's. Basically when you need servers than communicate with each other.

gavinray• 6 years ago

To provide context, understanding this requires a little bit of background knowledge about concurrency paradigms.

In concurrent programming, there are a few mental models/approaches you can use to achieve it. Each of them have different "values systems" and tradeoffs, if you will.

In a nutshell, you have:

- Locks (Mutex/Semaphore)

- Communicating Sequential Processes

- Software Transactional Memory

- Actor Model

The Actor Model is a particularly powerful paradigm because it isolates processes and works via message passing and spawning. The reason why Erlang/Elixir are fault-tolerant is because of the BEAM's process model, any given process (more or lesss) can fail and it's not a problem due to isolation.

What this library allows you to do is architect applications in ways such that they are much more resilient to failure and easier to scale out + parallelize/distribute.

It doesn't have to be a networked application either, any code process can be an actor. It applies to any software.

If you want a great overview of the Actor model, there are some slides here which do a fantastic job of illustrating it:

https://cs.nyu.edu/wies/teaching/ppc-14/material/lecture10.p...

michael_j_ward• 6 years ago

Do you have any good resources in learning more about these models / approaches?

davidw3• 6 years ago

Looks like good work! I'm curious about why I might use this instead of Erlang.

hopia3• 6 years ago

I was also wondering if this is aiming to be the Erlang for Rust developers, or rather a better Erlang. Either one would probably be worthwhile.

davidw3• 6 years ago

Yeah, either one is pretty cool.

If it's 'Erlang for Rust developers' I'd be curious to get a feel for how well it integrates with everything. A lot of what Erlang does is kind of difficult to shoehorn in via a library, but I don't know Rust well so maybe it all integrates in a very natural way.

lostcolony3• 6 years ago

Out of curiosity, what would you be looking for for "a better Erlang"? Most if not all of my issues were syntactical, or things that were given up as tradeoffs that I can't qualify as "better", so I'm curious what someone else's impressions are here.

dana321• 6 years ago

Runtime for what? Does it only run rust code?

pronoiac• 6 years ago

Odd name - bastion hosts, aka jumpboxes or homeboxes, are also the access points that bridge different security zones, like internet to a secure VPC.

xanth• 6 years ago

I wonder how this performs in comparison to actix[1] & axiom[2]?

1. https://github.com/actix/actix 2. https://github.com/rsimmonsjr/axiom

Bastion – Highly-available distributed fault-tolerant runtime

Related Stories