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.
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:
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.
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.
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.
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.
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 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 was commenting on the stuffed title. Not the content. That is why I specified that I had only read the title - because the comment was about the title.
My point was your point - pretty much exactly. You just assumed malintent, which is a problem HN seems to have.
If you want a title to be meaningful, stop stuffing it with words that don't accurately describe your tech.
"Bastion - Developer-friendly actors in Rust" would be a simpler title that clearly explained exactly what the library aimed for, with the details in the readme. From that, I would be interested in exactly which guarantees the library provided.
"Highly-Available" and "Fault-Tolerant" are the two most common of the three basic dist-sys principals chosen by projects (the third being netsplit tolerance, which is very rare compared to the number of other dist-sys technologies). Therefore, they tell me little.
"Distributed" can mean a number of things by itself - concurrent programming, GPUs, etc. are all "distributable". Of course, though, it's a buzzword, and thus could mean just about anything here.
A "runtime" when applied to a language usually means a standard or official supporting library runtime. You don't call ncurses a "runtime". To me, it meant that it took the Rust standard library and somehow made it "distributed", which made very little sense.
So yes, I read only the title. And I had something to say about the title. Shoot me.
You don't know enough about the title to comment on it until you know what it's describing. All your questions would have had obvious answers if you had done so. All the terms you raised FUD about were in fact being used in perfectly appropriate ways. So no one had to assume anything about your motive to conclude that your comment had negative value.
The whole point that the first comment tried to make was that titles should be as precise, detailed, and concise as possible. Exactly for the reason so that you should not have to read the whole page to understand what the title was about.
For me I had some of the same questions and “Bastion - an actor framework for Rust” would have covered the content as well.
Take the comment as general advice on how to define titles instead of an attack and flagging it to oblivion.
This would have been less accurate and far less interesting. A title that somehow referenced the Erlang roots of the design might be an improvement, but without comparing to an existing project I don't see a better way to summarize the project's full value proposition than exactly the title we saw. But of course if you don't actually read the article you can't find that out. You're allowed to think the title is stupid and not read the article, but then don't come here and pretend your ignorance is insight. That's why the top level deserved to be flagged to oblivion, though FWIW I only would have downvoted.
Flag it, sure. But it's a comment about the title. Others also have issues with the README, too, which I read directly after commenting and also found to be... strange.
Also, there are a lot of critiques about the tech itself - the fact that it's an at-most-once guarantee, the fact that the actor model doesn't work well in practice unless you model them more like traditional services, etc.
But my comment was just about the title. If you think it's dumb, that's your opinion.
I actually wasn't sure how to flag a post, or if I actually could, which is why I asked. I see now that if you click on the post you can do so.
Yes, I think your comment was not worthwhile and ultimately just took up space on the page, so I would have flagged it, but it's deleted. I would be very happy to have seen a post about things like at-most-once guarantees and the actor model.
I mean, how else are you supposed to write a title describing a project whose goals include such ideas? I think it's reasonable to have some additional explanation to justify it, and skimming the linked Readme satisfied me (as much as skimming can) that these terms are justified enough.
I'm not super familiar with any of those, but looking at BEAM at the cursory level, it has very little to do with "distribed-ness". It's a VM implementation with heavy focus on concurrency, which is only a small part of distributed systems and arguably not even in the same area of research.
You can make anything that is network-enabled a part of a distributed system, assuming you can express protocols within that 'thing'. If the VM supports bitwise operations, for example, you could support binary protocols to interface with anything else. The "VM" part of it, by itself, has very little impact on the entirety of the distributed system.
OTP provides the higher level abstractions to do what you are talking about. However, the BEAM VM itself provides a few features that when combined with the actor model and OTP, that makes it easier put together distributed system. Some of these are:
- Pre-emptible, lightweight processes that can be indefinitely suspended for relatively low memory cost.
- Immutable, copy-on-write for most data structures within the same lightweight process.
- Built-in queuing to support the Actor model (keeping in mind that this was designed before the Actor model was formalized)
- Generational garbage collection that avoids stopping the world or suspending the scheduler. (Avoids the garbage collection spikes seen in the Go runtime)
- Support for hot code reloading so live traffic can remain functioning. More important for telecom and stateful applications, and less fashionable now with the Kubernetes model of ephemeral workloads
All that taken together meant that you write the "distributedness" from the beginning, within the same VM, even though there are no network code involved. In other words, when writing Erlang/OTP code, you design for distributed computing in the very early stages, even if you initially deploy on a single node.
(Historical note: back before the BEAM VM supported multiple cores, people used to run separate BEAM OS processes per cpu and connected them together through network sockets on the same bare metal machine. These days, BEAM will automatically expand to use all the available cores of the machine).
Rust is already a fantastic partner for Erlang in the form of NIFs. Theoretically, a well-written Rust NIF can isolate memory errors and faults and would play nice with the rest of the app. NIFs have been historically problematic because they bypass these guarantees the BEAM VM makes for OTP apps and can be a source of crashers.
If Bastion has a similar runtime that has pre-emptible, light weight processes, that is very exciting. The rest of what BEAM provides involve guarantees around memory, something that Rust can provide in its own idiomatic way. (Except maybe the hot code reload).
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.
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.
I read through this and their documentation and literally have no idea what this feels like to the developer or how to start.