RSocket continues to feel like a weird Java-ism that doesn't really make much difference, but is kind of hipster-trendy has-cachet in JVM world. It doesn't seem to have any presence outside JVM. There's plenty of other well-adopted, also good protocols.<p>Right now there's some gaps to fill, & there's still a question of what higher level application layers to run atop it, but QUIC & HTTP3 are where I'd start if I wanted to invest myself in advanced technology that might begin to pay off big. QUIC is really a SCTP replacement, a multi-stream transport protocol, but it happens to ride atop UDP. RSocket calls itself an "application protocol" but seems to exist at around the same layer- it's api was ~2014 "reactive" hipster cool, but in terms of a protocol, it doesn't offer anything that I see that's particularly novel or intersting.<p>The RSocket FAQ has a section, "why not http/2", which both indicates the age of RSocket, & which pretty clearly illuminates that QUIC fits the bill: <a href="https://rsocket.io/about/faq#why-not-http2" rel="nofollow">https://rsocket.io/about/faq#why-not-http2</a><p>Edit: Oh! There's some value add listed in "Why not QUIC?"!<p>> <i>RSocket specifically is intended for layering on top of something like QUIC. QUIC offers reliable transport, congestion control, byte-level flow control, and multiplexed byte streams. RSocket layers on top of those things the binary framing and behavioral semantics of message streams (unidirectional and bidirectional), message-level flow control, resumption, etc.</i>