The README tells me mechanically what swim does but even with the example it’s quite abstract and I don’t know why I would choose to build with swim, what it’s similar to, or what it’s especially good at.

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.

Maybe stating the obvious but took me an embarrassingly long time to clock this:

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.

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

Why do so many products that aren't an operating system calling themselves WhateverOS?

Looks very similar to Akka, where agent is actor and Lifecycle is Behaviors.

An interesting project for a complex task - streaming stateful processing.

This is super cool!! Back many years ago now I had a project that dealt with realtime data + geofences so I used tile38. I'm super curious to check this out!

What about adding differential data flow?

How does this compare to Erlang?