Many of the example applications are corresponding code to our developer website which contains guides for them: https://www.swimos.org/server/rust/ We will get this updated as it isn't clear

Thank you for the feedback! We could definitely improve the documentation and we will expand on the "why?"; we will get an updated readme up that expands on this in more detail. Could you please tell me which part of the website clearly explained it to you such that you understood the value proposition?

I am someone who initially really struggled with understanding whatever the Kafka team thinks their explanation is. Even after working on streams and pub sub messaging I still struggle with their explanation.

However, I completely resonated and understood what you guys have built. We actually built something very similar but it was over websockets with protobuf3 just to emulate this exact behaviour. We we're using it for IoT-esque devices which send their data constantly but we needed to keep track and update certain fields when devices would connect and disconnect.

We'll be open sourcing our implementation soon. I will happily want to rebuild it with this, and maybe add a sprinkle of protobuf3 to make sure messages are type safe.

That is correct. We're working towards replacing our Java implementation with the Rust version and then provide bindings to Java

We hope that it goes well and we would love to hear your feedback!

The Swim Rust SDK contains software framework for building stateful applications that can be interacted with via multiplexed streaming APIs. It is built on top of the Tokio asynchronous runtime and a Tokio runtime is required for any Swim application.

Each application consists of some number of stateful agents, each of which runs as a separate Tokio task and can be individually addressed by a URI. An agent may have both public and private state which can either be held solely in memory or, optionally, in persistent storage. The public state of the agent consists of a number of lanes, analogous to a field in a record. There are multiple kinds of lanes that, for example, lanes containing single values and those containing a map of key-value pairs.

The state of any lane can be observed by establishing a link to it (either from another agent instance or a dedicated client). A established link will push all updates to the state of that lane to the subscriber and will also allow the subscriber to request changes to the state (for lane kinds that support this). Links operate over a web-socket connection and are multiplexed, meaning that links to multiple lanes on the same host can share a single web-socket connection.

There's a number of example applications available here: https://github.com/swimos/swim-rust/tree/main/example_apps If you're interested in getting started with it a developer guide is available here https://www.swimos.org/server/rust/developer-guide/ as well as reference documentation here https://www.swimos.org/server/rust/

Previously on HN:

- SwimOS: Distributed platform for building stateful, real-time streaming apps https://news.ycombinator.com/item?id=22920764

- Real-time traffic light status in Palo Alto powered by swim.ai https://news.ycombinator.com/item?id=19234286

How is it real time if you are using tokio? What latency and deadline guarantees are you able to provide?

"real time" as in figma multiplayer not as in control system for a car (I'm assuming, never used SwimOS)

Doesn't run on bare metal though?

It doesn't unfortunately but this is something that we have discussed internally about targeting. We would be interested to hear about your use-case for it!

I'm just picky about maintaining purity of the term "OS".

If "OS" can include WebKit and Lua and anything with a file API and an interpreter then "OS" just means "an abstraction" and I don't need two words for the same thing

Like, Chrome is not an OS, no matter how big a bonus someone at Google got for that clever bit of marketing.