Thanks! Actually, the mentioned PR was just an internal merge; the one to the master branch is this one https://github.com/apache/iggy/pull/2299 which happened last week :)
Sans-IO is for clients only, and we'd like to introduce it one day to SDK to support the different runtimes as well as the blocking, sync client.
There's a core difference between the message queue and the stream, and one of them is that the append-only log acts as a simple database from which multiple independent consumers can read records at the same time; hence, you don't truncate the append-only log unless specified in its settings via a particular cleanup policy (e.g. based on message expiry or its allowed size).
Lack of traction basically. We ran out of time and money. Also we, maybe wrongly, did not feel like we could compete with the big ones without clustering. Yet we had a lot of fun building it. It was a thrill to see our product deliver performance on par or above in-memory messaging systems while being fully persisted and fsync’ed. I’m sure you know what I mean ! Good luck with Iggy anyway. Looks like you are on the right track !
Probably because there's a very low value in building message streaming framework once you've done the basics: how do you come to, say, a trading broker and say "your order management system could be just as fast with my other messaging framework".
He did it to learn and have fun, but finishing it to be prod-ready would require at least one user.
That was indeed a big parameter. We missed someone on the team able to connect to us to one or two large early adopters. We learned that building a good product and building a company selling it are two very different things !
I did some dotnet OSS in the past, but there's something special about Rust community and I guess that if I'd picked another language instead, I wouldn't gather such an amazing team :)
As already mentioned, we've decived to use monoio, just to have something to begin with, it will take at least a few months to rewrite the core parts to make use of io_uring and thread-per-core approach (if feasible), so staying on the bleeding edge is more like a sandbox for us - we might decide to go with another runtime, like glommio, mfio or something else.
Ah cool! Just to be clear, I think you should do whatever you feel is best for your project. I don't see this in any sort of moral terms, purely engineering ones, and there are good reasons to use nightly just like there are good reasons to use stable.
Can't say for sure, we share some of the same concepts that can be found in Kafka or RabbitMQ Streams, but at the same time, try to build something from the ground up and focus on low-level I/O improvements :)
