You could have read the entire README in the time you spent posting something based off your assumptions.

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.

> “Bastion - an actor framework for Rust”

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.

> (and full disclosure, I've only read the title)

Is there a way to just get posts like this deleted?

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.

Because my comment was about the title. Not about the content.

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.

How would you describe elixir or erlang, wrt to the distribed-ness of BEAM?

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).