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.
I had a similar reaction, and assumed I'm not the target audience. (Including skimming the examples folder and not being sure where I would use one of them) I have a hard time understanding the purpose of these abstract libraries; I assume people who have had the problems they solve recognize their utility.
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.
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.
I think the examples could answer that question. They’re linked at the end of the explanation in the README. However, I think each example ought to have a README.
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
Having to study an example before getting a clear enough idea what to look for definitely narrows down the potential audience. Examples are very useful and important, but, unless they fit in 5-7 lines, they are the second step.
The first step should be a few bullet points listing the key reasons behind the framework and the key benefits it provides.
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.