Created a short summary for my own use: In the context of imperative programming: 1. List-based functional programming is eagerly evaluated. 2. Stream() introduced in Java 8 and is the seam showing we're not programming imperatively anymore. Is it required, though? a. imperative - what and how b. declarative - what and *not* how + higher order functions = FP. Code reads like the problem statement, through "internal iteration"/ "iteration on autopilot" Mutability is OK, but shared mutability is not. 3. In OOP we encapsulate moving parts - in FP, we eliminate them. 4. Is stream API slow - you don't want a faster bicycle, but a rocket - EASIER TO PARALLELIZE 5. List is bucket, Stream is pipeline. You don't store water in a pipeline, you just move it through there. 6. Functional composition (builder pattern) is essential. 7. Lazy evaluation example - removing the terminal (collect) method - functions not being called anymore, as result not needed. 8. Many languages give programming pattern, such as Groovy, but laziness not there, as it depends on implementation. Limitations of streams: 1. Single use only. Example where a stream is assigned to a variable, printed and then used with different filter condition. Result: IllegalStateException: stream has been operated on or closed. a. Concept: streams like QTips - use once and throw away. 2. Not possible to fork in the middle. Only a single terminal operation. 3. How do you deal with exceptions: sorry :(. Exception handling is an imperative-style idea: call a function, which calls a function, etc. and destroys your callstack. a. Scala has Mono monads and Either objects - provides safe handling, which is propagated and used in downstream stages. Lacks cohesion! b. Still good luck - we want pure functions and exceptions normally come from impurity. Reactive systems: 1. Came out of Microsoft research, but just a new name for old concept - system that reacts to stimuli 2. Four pillars of reactive programming: a. Elasticity b. Message-driven c. Responsive d. Resilience - circuit breakers built in, partial access to application 3. Close to the 80's concept of dataflow computing: d → f → d →f a. Instructions ready to fire when the data is available b. Serverless computing (AWS Lambda) == dataflow programming. At the minute computation is ready and prepared it can run on ANY server with predefined affinity 4. Reactive programming is FP++ - builds on lazy evaluation and functional composition a. Example with Flowable and subscribe on it 5. Both Java Streams and Reactive ones push data, regular iterators pull. They are similar to Observable, you register to it and it pushes data to you. 6. Both can return 0, 1 or more data. 7. Java 8 Streams deal only with data. RS contain three channels (Data, Err, Complete). In RS error is just another form of data. 8. RS are asynchronous, so you are not locked into parallelism (sync). 9. RS can handle consumer back-pressure. 10. Multiple subscribers in RS, where single pipeline in Java Streams 11. Interface differences: a. Reactive Stream: - Publisher - Subscriber - Subscription - session between emitter and subscriber, can hold context - Processor - publisher + subscriber - Implementations: RxJava, Akka, Reactor (Spring 5), RSocket b. Java reactive streams - same interface, since Java 9 - in the java.util.concurrent.Flow.* class
What a great lecture. When I saw the video was 2.5 hours I figured I would skim over in about 10 minutes on the off chance I would see something interesting but instead I am enjoying the entire thing. Fantastic speaker.
If you wanna skip the Java 8, streams and Functional and imperative programming introduction and go straight to Reactive stuff, this is the moment , go to 39:00
Once you start listening to Venkat, you just can't stop yourself to keep listening. And after completing this one you will be searching for more such talks by Venkat. I just wonder, people will even be listening to him if he speaks any useless words, thats the aura & way of presentation he has got :)
@37 Exceptions. You can be proactive by using a filter to eliminate problematic data from stream. This works for many kinds of cases, e.g. if the list of numbers in the example contained a null.
Thanks again for providing inspiring and great talk of the Reactive Streams concept. Hats off to your relentless contribution to the Java community. You are a truly Inspiring tech talker.
41:40- Its a classic example/reality about what people are losing in the name of innovation & technology. We are not getting it now. Like people currently pay to different consultants & coaching centres to learn to interact with computers, sooner the same people will be paying to learn to interact with other humans. Days are not far when people will not be driven by human intellect, common sense & self awareness but all people's lives will be controlled & driven by these tech devices.
This is the exact part where I was confused. From baeldung, explaining it: "Streams terminal operator is just that, terminal, pulling all the data and returning a result". So collect() is pulling data from the source.
I don't understand that how we can still consider the error/exception as another kind of Data when we are still not receiving it as a data, means we are still receiving error/exception in other channel & in a stream of data if one item is causing some error/exception, then why we stop processing other items by default, why data channel is closing...I think the day we start getting both data & error on the same channel & no-one can differentiate whether the item is data or some error from outside then I think it will be making error/exception the actual first class citizen...and then the decision of closing the data channel on some exception will be with the receiver also, so either source/publisher stops emitting more data on some exception or the receiver can stop receiving the data on some exception in the data channel...
Imperative is more performance. Streams are extremely slow. So nothing is outdated. Try solving leetcode problems with newer style code. They will be extremely slow
Not a very concrete explanation. He never describes what dataflow pipeline is and therefore makes the comparison between AWS and dataflow confusing for anyone who doesn't fully understand the former. And what's the point in saying we "rebranded" it; it doesn't help me to understand either AWS or dataflow.
and? lazy evaluations and the whole functional paradigm came out decades before OOP. there are other lectures where venkat gets more into historical facts and always mentions the fact that these are very old techniques that are becoming popular.so your comment really makes no sense. such a stupid comparison.
Created a short summary for my own use:
In the context of imperative programming:
1. List-based functional programming is eagerly evaluated.
2. Stream() introduced in Java 8 and is the seam showing we're not programming imperatively anymore. Is it required, though?
a. imperative - what and how
b. declarative - what and *not* how + higher order functions = FP. Code reads like the problem statement, through "internal iteration"/ "iteration on autopilot"
Mutability is OK, but shared mutability is not.
3. In OOP we encapsulate moving parts - in FP, we eliminate them.
4. Is stream API slow - you don't want a faster bicycle, but a rocket - EASIER TO PARALLELIZE
5. List is bucket, Stream is pipeline. You don't store water in a pipeline, you just move it through there.
6. Functional composition (builder pattern) is essential.
7. Lazy evaluation example - removing the terminal (collect) method - functions not being called anymore, as result not needed.
8. Many languages give programming pattern, such as Groovy, but laziness not there, as it depends on implementation.
Limitations of streams:
1. Single use only. Example where a stream is assigned to a variable, printed and then used with different filter condition. Result: IllegalStateException: stream has been operated on or closed.
a. Concept: streams like QTips - use once and throw away.
2. Not possible to fork in the middle. Only a single terminal operation.
3. How do you deal with exceptions: sorry :(. Exception handling is an imperative-style idea: call a function, which calls a function, etc. and destroys your callstack.
a. Scala has Mono monads and Either objects - provides safe handling, which is propagated and used in downstream stages. Lacks cohesion!
b. Still good luck - we want pure functions and exceptions normally come from impurity.
Reactive systems:
1. Came out of Microsoft research, but just a new name for old concept - system that reacts to stimuli
2. Four pillars of reactive programming:
a. Elasticity
b. Message-driven
c. Responsive
d. Resilience - circuit breakers built in, partial access to application
3. Close to the 80's concept of dataflow computing: d → f → d →f
a. Instructions ready to fire when the data is available
b. Serverless computing (AWS Lambda) == dataflow programming. At the minute computation is ready and prepared it can run on ANY server with predefined affinity
4. Reactive programming is FP++ - builds on lazy evaluation and functional composition
a. Example with Flowable and subscribe on it
5. Both Java Streams and Reactive ones push data, regular iterators pull. They are similar to Observable, you register to it and it pushes data to you.
6. Both can return 0, 1 or more data.
7. Java 8 Streams deal only with data. RS contain three channels (Data, Err, Complete). In RS error is just another form of data.
8. RS are asynchronous, so you are not locked into parallelism (sync).
9. RS can handle consumer back-pressure.
10. Multiple subscribers in RS, where single pipeline in Java Streams
11. Interface differences:
a. Reactive Stream:
- Publisher
- Subscriber
- Subscription - session between emitter and subscriber, can hold context
- Processor - publisher + subscriber
- Implementations: RxJava, Akka, Reactor (Spring 5), RSocket
b. Java reactive streams - same interface, since Java 9 - in the java.util.concurrent.Flow.* class
Woaah Fantastic work Evgeni!!
Hello from Brazil, I just imagine how amazing could be a class from Dr. Venkat at University of Houston. Lucky students.
39:00 reactive programming
41:00 reactive application
42:30 reactive systems
46:40 reactive programming principles
1:01:00 reactive streams
1:01:00 data flow computing
1:07:54 channels of communication
1:13:17 similarities with streams and differences
1:27:00 circuit breaker
1:39:30 non blocking and back pressure
1:51:00 multiple subscribers
2:00:00 reactive streams api
2:01:44 publisher
2:02:36 subscriber
2:03:00 subscription
2:05:50 processors
2:08:24 reactive libraries
2:10:45 java 9 reactive streams api
Not all heroes wear cape
What about first 39 minutes?
One thing about Venkat’s talks - every time I watch I learn something new. Thanks a million for the talk
First talk I saw... pretty impressive.
5 years on from the video, and what he says hold true! Lots of libraries, and lots of usage of reactive programming currently.
If Teaching is an art, this person is the Piccaso of it. Thanks !!!
What a great lecture. When I saw the video was 2.5 hours I figured I would skim over in about 10 minutes on the off chance I would see something interesting but instead I am enjoying the entire thing. Fantastic speaker.
He is just amazing. Pure 150 mins of infotainment .
Venkat sounds like... you're trying to figure out the perfect playback speed and you change it all the time. Great talk!
If you wanna skip the Java 8, streams and Functional and imperative programming introduction and go straight to Reactive stuff, this is the moment , go to 39:00
40:20 "...every 10 year, we give a new name to what we already do and get really excited about it..." LOLzzzzz
Once you start listening to Venkat, you just can't stop yourself to keep listening. And after completing this one you will be searching for more such talks by Venkat. I just wonder, people will even be listening to him if he speaks any useless words, thats the aura & way of presentation he has got :)
Absolutely love this guy
Great talk. I learned so much. Thanks
Teaching at its best.. simple...loved the energy..thank you for sharing this video..
Good explanation. Thanks a lot
@37 Exceptions. You can be proactive by using a filter to eliminate problematic data from stream. This works for many kinds of cases, e.g. if the list of numbers in the example contained a null.
I think in spring 5 it’s not Flow, it’s Flux
And it’s not part of spring 5, it’s part of project reactor and spring 5 uses it for webflux
Thanks again for providing inspiring and great talk of the Reactive Streams concept. Hats off to your relentless contribution to the Java community. You are a truly Inspiring tech talker.
This talk is really helpful..:)
Great Summary!
The explanations for some of the concepts were quite illuminating. Thanks!
Good presentation, lot of words at x1.25. A plus for tackling the topic of exception handling support in streams API or rather lack of it.
Great! Very exciting, thanks.
what is the software he's using? is it emacs org mode? looks like he's typing // that gets transformed to a 🗸..
nice talk. Thank you for uploading conference talks
41:40- Its a classic example/reality about what people are losing in the name of innovation & technology. We are not getting it now. Like people currently pay to different consultants & coaching centres to learn to interact with computers, sooner the same people will be paying to learn to interact with other humans. Days are not far when people will not be driven by human intellect, common sense & self awareness but all people's lives will be controlled & driven by these tech devices.
2:30 of no-stop talking! then! that what I call dedication
At 6:54 what shortcut did Venket use to complete that list, can anyone help me please?
Nice explanation.
For Flowable, did they baked-in RxJava in Java 9?
Reactive is push. Java streams don't push items. They have to be pulled.
This is the exact part where I was confused. From baeldung, explaining it: "Streams terminal operator is just that, terminal, pulling all the data and returning a result". So collect() is pulling data from the source.
So Java Reactive Stream is like RxJs with fewer operators.
I don't understand that how we can still consider the error/exception as another kind of Data when we are still not receiving it as a data, means we are still receiving error/exception in other channel & in a stream of data if one item is causing some error/exception, then why we stop processing other items by default, why data channel is closing...I think the day we start getting both data & error on the same channel & no-one can differentiate whether the item is data or some error from outside then I think it will be making error/exception the actual first class citizen...and then the decision of closing the data channel on some exception will be with the receiver also, so either source/publisher stops emitting more data on some exception or the receiver can stop receiving the data on some exception in the data channel...
At 2:09:09, I believe he meant Mono & Flux
wondering what IDE he uses...
In this presentation he is using IntelliJ IDEA.
Funniest diss of the Thread API at 19:36
How to get that background for. Textmate
Supermario :)
Imperative is more performance. Streams are extremely slow. So nothing is outdated. Try solving leetcode problems with newer style code. They will be extremely slow
Leetcode issues are not real world issues. Those 2 are parallel domains of computing.
Streams are literally just wrappers for iterators with some extra metadata. They're far from "extremely slow".
Streams and Qtip comparison - actually Qtip are always bad shall never use :)
38:00
Not a very concrete explanation. He never describes what dataflow pipeline is and therefore makes the comparison between AWS and dataflow confusing for anyone who doesn't fully understand the former. And what's the point in saying we "rebranded" it; it doesn't help me to understand either AWS or dataflow.
Lazy evaluations work very similar to C# (.Net)... which launched this feature 7 years before Java.
and? lazy evaluations and the whole functional paradigm came out decades before OOP. there are other lectures where venkat gets more into historical facts and always mentions the fact that these are very old techniques that are becoming popular.so your comment really makes no sense. such a stupid comparison.
wow.. 2hours++ nonstop talking...
the speaker is too fast.Please slow down man.
Use that pause button.
i watched at 1.5x