Show HN: SwimOS Rust – A framework for real-time streaming data applications
github.com
github.com
I think with frameworks you should make the value proposition very clear otherwise it’s a tall ask for someone to adopt a way of building. Versus a library which is easy to drop into existing software to solve a specific, scoped task.
I guess a bunch of what I’m looking for is discussed in the main repo of your project, but even there it’s a bit heavy on the “what” and too light on the “why” for me. This is a deep framework. I work on a realtime reactive app and am currently building stateful services on Kafka + Typescript + SQLite, so I think I’m squarely in your target customer demographic.
It’s not until I found the website that the value proposition is clearly described. I encourage you to copy-paste the headline of your website to all the components of your framework, so it’s easier for a casually interested person on HN to grok what it’s all about.
EDIT: there’s like a 1% chance I actually do convert, since I realize I could run my existing Typescript business logic in a Rust agent via Deno… perhaps the scattered documentation hunt on a Sunday is good marketing strategy after all.
As a reference point for rust libs I've worked with recently: I see things like EGUI: This clearly is a library that allows you to add a GUI to programs. Or Bio: This lets you read and write FASTA format DNA etc sequences, find matches in sequences etc. Bincode: Provides a "derive" that allows you to easily serialize data to and from binary formats. Or the various embedded infrastructure libs that provide high-level APIs for performing hardware options. (I/O, ADCs, send a packet over USB or a radio etc) By contrast to these and every other lib I've worked with, Swim is abstract.
I start wondering if I'm too dumb or otherwise incapable of reasoning abstracting to understand the Async part of Rust's ecosystem.
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.
Here’s the first one I looked at. I’m wondering when to use an event instead of a command. https://github.com/swimos/swim-rust/tree/main/example_apps/v...
The first step should be a few bullet points listing the key reasons behind the framework and the key benefits it provides.
SwimOS is an existing streaming framework (Java-based) targeted at full stack / app development.
This announcement is a new Rust SDK for the above - not a new framework.
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
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.
An interesting project for a complex task - streaming stateful processing.
In contrast, SwimOS is designed for high-performance streaming, boasting a heavily optimized WebSocket implementation that leverages multicast, multiplexing, and differential dataflow (delta encoding) to efficiently handle massive data volumes. SwimOS utilizes zero-cost abstractions and lock-free mechanisms to achieve its goals. Its primary use cases are data observability and real-time collaboration applications, with an emphasis on in-memory processing and recent data. This processing window is similar to a retention window in distributed log technology like Kafka, where the focus is on handling large volumes of data in real-time to enable timely decision-making, without necessarily storing all the data long-term.
While both technologies share some similarities, their design and use cases make them suited for very different problem domains.