HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bastion-rs
bastion
Rust2019–2023
bastion-rs / bastion

bastion

Highly-available Distributed Fault-tolerant Runtime

11Distinct people
12Mentions
0Explicit recommenders
2.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Highly-available Distributed Fault-tolerant Runtime

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2019-12-15 17:18:26 UTC to 2023-08-06 15:34:43 UTC.

0123452019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC413
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

What Hacker News says

12 sources
> Pre emp scheduling Userspace pre-emptive schedulers do not incur the same level of overhead that kernel threads would normally have. To address another comment you made in another chain, Erlang accomplishes pre-emption through reductions which is roughly equivalent to ~4000 function calls, if I remember correctly and if I have read the correct documentation, before it yields the Erlang process. Other forms of async to my knowledge essentially queue a task while the main thread of execution continues before awaiting; and the queued task is run in some form of thread pool (or other forms of executors). Without going too deep into this subject (and assuming I have made no logical errors) it is possible to have misbehaving tasks in async tank performance and latency, while the same misbehaving process in Erlang wouldn't. See Saša Jurić's de
Read the rest
monstration [1] for an example. Do keep in mind that async is not forte, what I have stated is merely my observations. I write primarily with kernel threads. This is why it is possible to spin up millions of, in Erlang terms, processes with minimal overhead. See this article by the Phoenix Framework team regarding an experiment on having two million active websocket connections on a single (albeit beefy) host [2]. > This and everything else is very nice but do we need a full VM for that? See [3] regarding an effort to port the Erlang process and supervision strategy to Rust. In my naive view, it is possible to write something similar to BEAM in another language, but the more troubling portion of the work is to jury-rig the original language into a concurrency model it isn't designed for whereas Erlang by contrast was created purely for this task. [1] https://www.youtube.com/watch?v=JvBT4XBdoUE [2] https://www.phoenixframework.org/blog/the-road-to-2-million-... [3] https://github.com/bastion-rs/bastion
In An Elixir adoption success story
> 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
In Bastion – Highly-available distributed fault-tolerant runtime
Worth to mention that Bastion has been developed a lot and it has its own design(in simple terms SMP based executor) to leverage asynchronous programming (with fault-tolerant manner). It isn't dependent on any runtime. You can mix and use any runtime with it and supplies hierarchical reduction based concurrency. We proudly take Erlang's runtime model and implemented it in Rust. Moreover, we are currently working on distributed carrier protocol to make Bastion form a cluster, exchange data and recover from partial failures in distributed workloads too. Local failures are recovered and we have built-in lifecycle management. Maybe after these words you might want to take a look: https://github.com/bastion-rs/bastion You can write a fully fault-tolerant program with our macro mechanisms too: https://github.com/bastion-rs/fort Here our distrib
Read the rest
uted protocol repository: https://github.com/bastion-rs/artillery And our landing page: https://bastion.rs/
In Show HN: Coerce – Actor runtime for Rust using async/await and tokio channels

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.