> Most stream processing frameworks available today - Kafka, Pulsar, Flink, Spark, etc. - were born in the Big Data era (...) > These Java-based stream process

> Most stream processing frameworks available today - Kafka, Pulsar, Flink, Spark, etc. - were born in the Big Data era (...) > These Java-based stream processing platforms Maybe you mean JVM based? That's not the same thing. E.g. Kafka is written in Scala, not Java. > Java-based systems demand significant CPU and memory resources, making them unsuitable for extending stream processing to edge devices. Well okay, but there is a big difference between doing stream processing on a small device and in a central data platform. That comparison doesn't make so much sense. > Jars were designed at the dawn of the Internet when Browsers were rudimentary HTML readers and programs required runtime applets (aka. sandboxes) to operate. These sandboxes have been riddled with security vulnerabilities Wait - look at Android. It runs applications on the JVM (well, their own, that is) very successfully. I think it's the opposite: the JVM comes with a lot of power regarding the control of execution. This is a pro, not a con in this context. You will have to rebuild some of that if you use Rust. In addition, while JVM applications might be quite memory hungry, the performance isn't very far from native code most of the time, thanks to the optimizations that happen at runtime. Don't get me wrong. Rust is a great language and I'm sure it can gain you significant performance improvements when enough time&resources are put into it. But this post seems to have an overly negative view on the JVM and its ecosystem, which makes me wonder if the motivation for building Fluvio is really in the right place.