I have hard time understanding what this is. Is an alternative to docker somehow? What other framework/platform would bastion compete with?
Looks like Akka Cluster for rust?
Bastion – Highly-available distributed fault-tolerant runtime
31–40 of 45 posts
Re: Bastion – Highly-available distributed fault-tolerant runtime
#32Looks like good work! I'm curious about why I might use this instead of Erlang.
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.
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.
Re: Bastion – Highly-available distributed fault-tolerant runtime
#33Earlier quoted context omitted.
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.
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.
Elixir is pretty nice in that it cleans up some of the cruft from however many years ago.
Making it faster for certain things, as long as that doesn't hurt it in other ways, is always going to be a win.
Re: Bastion – Highly-available distributed fault-tolerant runtime
#34Earlier quoted context omitted.
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.
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.
I'm honestly no expert on the subject. I have virtually zero experience with Erlang language. And I don't know a thing about Rust. However, if that counts I have read large parts of Joe Armstrong's PhD thesis about distributed systems and written plenty of Elixir.
It may be wrong to say we need a better Erlang, but for modern web development we certainly could use a fair bit more compiler enforced type safety for writing more correct programs. Mostly due to the lack of a proper type system, Erlang is not particularly expressive as a language, although its primitives (processes & message passing) are well geared exactly for what it focuses on.
Erlang focuses strongly on fault-tolerance and subsequently on high availability, but I'm not sure this perk is so significant benefit anymore compared to various other runtimes spinning the wheels of your typical web server in a cloud setup. We rarely need to write servers anymore that keep running for many years straight without a restart, only patching code via hot reloads.
Just my take but since you asked, trading some fault tolerance for more correct programs would therefore probably be a fair trade-off for a new kind of Erlang.
Re: Bastion – Highly-available distributed fault-tolerant runtime
#35Can someone elaborate use cases for this?
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…
Do you have any good resources in learning more about these models / approaches?
Re: Bastion – Highly-available distributed fault-tolerant runtime
#36Earlier quoted context omitted.
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.
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.
Syntax is fine, to me the weak typing gets old. Yes there's tooling to help annotate and check usage of annotated types but it's not nearly as good as Rust in typing help to make correct programs.
Re: Bastion – Highly-available distributed fault-tolerant runtime
#37Earlier quoted context omitted.
Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).
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.
> How do you cleanly stop it
The JVM manages this - there are many options:
- reading a flag - patching the running - changing memory protection and causing a segfault
Re: Bastion – Highly-available distributed fault-tolerant runtime
#38Earlier quoted context omitted.
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.
I'm honestly no expert on the subject. I have virtually zero experience with Erlang language. And I don't know a thing about Rust. However, if that counts I have read large parts of Joe Armstrong's PhD thesis about distributed systems and written plenty of Elixir. It may be wrong to say we need a better Erlang , but for modern web development we certainly could use a fair bit more compiler enforced type safety for wr…
Thanks for the reply!
Yeah; I always added type annotations to my code and ran Dialyzer...I wish there was a stricter compilation mode for that. That said, I really liked the 'optimistic' part of it, so I didn't spend a large amount of time correcting my type specs when proper testing proved it work.
I can agree with bfrog's comment too; Rust's typing can definitely help eliminate a bunch of classes of bugs...but honestly I'm not sure I ever ran into them using Erlang in production anyway. Immutable data + message passing tends to make it easy to implement things correctly, whereas some of Rust's more standout features seem designed to solve problems caused by the language itself picking a different set of tradeoffs (i.e., borrow checking as part of what is necessary to manage memory without risking it going out of scope prematurely, or being unable to be reclaimed at a deterministic time by the compiler). I'm not familiar enough with Rust myself to really comment though; I just know that in two and a half years of production Erlang, the only bug we ever encountered was caused by a C driver (and our own bad design in not circuit breaking calls to it, leading to restarts that trickled up the supervisor chain under heavier load than we'd tested for. None of which would Rust have been able to help us with. In fact, even the driver, the issue was an unnecessary network call that sometimes hit an empty cache, causing a huge network hiccup that led to an unhandled timeout). It got 'correctness' as well as 'fault tolerance'. At least as much as a language can (i.e., we could still implement the wrong things, such as when we implemented an O(N^2), but correct, algorithm, that we had to fix to an O(N) when we noticed certain calls being too slow)
Re: Bastion – Highly-available distributed fault-tolerant runtime
#39Odd name - bastion hosts, aka jumpboxes or homeboxes, are also the access points that bridge different security zones, like internet to a secure VPC.
Re: Bastion – Highly-available distributed fault-tolerant runtime
#40Earlier quoted context omitted.
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…
Do you have any good resources in learning more about these models / approaches?
I’ve only skimmed this, but it seemed reasonable.
https://pragprog.com/book/pb7con/seven-concurrency-models-in...