I think the Java community has done something really amazing here. As a C# fanboy it's hard for me to admit, but while reactive extensions have been in the C# ecosystems for much longer - it seems like a wide variety of vendors lined up backing Reactive Streams in Java in their drivers (where there aren't a lot of vendors backing up their kind words with an Rx implementation in C#). Nice work.
I remember seeing a talk on this around a year ago, and while it did have some important backing and solve some interesting problems, there wasn't much in terms of examples of people using it in production.
Is this still the case? I guess with it hitting 1.0 it's more likely now, but I'd still be interested to hear if anyone's had much experience with this up until now.
Reactive Streams are just interfaces meant to make interconnection and usage of different libraries easier and faster. The document is meant to avoid the well famous "similar library, different names for same concepts". There's nothing more than that.
In the same page you can find a list of compliant implementations like AKKA or RxJava, so you can easily check out one of them and see how they are implementing these concepts under the hood. The general purpose is good, it makes the switch from framework X to Y easier with the declared goal of provide a standard for asynchronous stream processing with non-blocking back pressure, but, as said before, there's nothing more than that.
About the production, well, some of the listed libraries are widely used, so I guess there are a lot of people actually using this concept in production.
Then, if you want to go further, you can search for Duality, that seems an evolution of Reactive Programming and Reactive Streams.
For evidence of people in production now, you will find more users of RxJava which has been providing similar functionality for a while (including backpressure support).
I think this convention is one for the future and this release marks the start of adoption. I think the hope is that more implementations will come in the future and one goal is to allow the simple connection of reactive streams and allow the building complex distributed systems.
I don't think it's meant to be used directly. It's a minimal api (just 4 interfaces) that can be used by various reactive frameworks to interoperate with eachother.
While this looks very interesting, and I'll probably push for using it in production shortly, I can't help but wonder what some of their marketing talk even means.
non-blocking back pressure
How does that even relate? All I can think of is sticking a potato into a car exhaust.
That's not a marketing talk but an important technical term instead. See this for a quick reference: https://github.com/ReactiveX/RxJava/wiki/Backpressure .
It is important to understand before even thinking about using reactive streams in production.
This is a great vision, but without trying to be a jerk, I have to wonder: isn't this just a restatement of what Erlang/OTP has been doing for at least 20 years? I haven't learned the language yet, so it's a serious question.
And if you want "Erlang validation" it's hard to beat WhatsApp's $19B acquisition. (I doubt that Facebook will be releasing any open source Erlang code any time soon!)
What does this have to do with Erlang? As far as I know, Erlang doesn't have a concept of a "stream" nor any particular mechanism for handling back-pressure.
I haven't used erlang - that said, one reason might be that it's dynamically typed by default, and that the extensions for a type system have had mixed success:
"Phil Wadler and Simon Marlow worked on a type system for over a year and the results were published in [20]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process messages."
v1.0.0#specification reads:
> Or another implementation could fuse the operations to the final consumer:
> nioSelectorThreadOrigin | map(f) filter(p) consumeTo(toNioSelectorOutput)
Having control over how to fuse a chain of functions is very interesting. Do any of the implementations allow use of mutable state when fusing a chain of functions with the same signature.
inglor|10 years ago
rozza|10 years ago
jordanrobinson|10 years ago
Is this still the case? I guess with it hitting 1.0 it's more likely now, but I'd still be interested to hear if anyone's had much experience with this up until now.
bontoJR|10 years ago
In the same page you can find a list of compliant implementations like AKKA or RxJava, so you can easily check out one of them and see how they are implementing these concepts under the hood. The general purpose is good, it makes the switch from framework X to Y easier with the declared goal of provide a standard for asynchronous stream processing with non-blocking back pressure, but, as said before, there's nothing more than that.
About the production, well, some of the listed libraries are widely used, so I guess there are a lot of people actually using this concept in production.
Then, if you want to go further, you can search for Duality, that seems an evolution of Reactive Programming and Reactive Streams.
rozza|10 years ago
I think this convention is one for the future and this release marks the start of adoption. I think the hope is that more implementations will come in the future and one goal is to allow the simple connection of reactive streams and allow the building complex distributed systems.
Also interestingly it looks like this concept might make it into jdk9 as Flow - https://github.com/reactive-streams/reactive-streams-jvm/iss...
oelang|10 years ago
CountHackulus|10 years ago
non-blocking back pressure
How does that even relate? All I can think of is sticking a potato into a car exhaust.
igor-tn|10 years ago
GFK_of_xmaspast|10 years ago
javajosh|10 years ago
And if you want "Erlang validation" it's hard to beat WhatsApp's $19B acquisition. (I doubt that Facebook will be releasing any open source Erlang code any time soon!)
So what's the deal? If you believe in the http://www.reactivemanifesto.org/ wouldn't you be better off just biting the bullet and learning http://www.erlang.org/?
panic|10 years ago
ubertaco|10 years ago
dmeb|10 years ago
"Phil Wadler and Simon Marlow worked on a type system for over a year and the results were published in [20]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process messages."
http://learnyousomeerlang.com/types-or-lack-thereof#for-type...
fanstatic|10 years ago
Having control over how to fuse a chain of functions is very interesting. Do any of the implementations allow use of mutable state when fusing a chain of functions with the same signature.