JDD 2018: Reactive programming: lessons learned by Tomasz Nurkiewicz

Reactive programming enables amazing things. Highly scalable systems consuming just a fraction of CPU compared to ordinary applications? Sure. Responsive, low latency and high throughput? No problem. Small memory and OS footprint? Out-of-the-box. Any reason not to love reactive? I will share some of my experiences with reactive programming and systems. Where it shines and where it was an over-engineering. What are the hidden costs and common mistakes? How to convince your teammates to start the reactive journey. And more importantly: how to convince your teammates, that going reactive is a dead end. On a case-by-case basis.

[analogpl]

Much appreciated honesty. For someone who spends most of his time reading someones broken code (rather than writing something new) reactive code looks like hell. Hearing that its still awesome after concise criticism is like a light in a tunnel.

[juanandrade]

This talk is a superposition of both:
>existing to avert people from coding reactively.
>existing because its expounder did not followed its first rule.

[oldratlee]

Traffic share!

Lot's insights like

1) Netflix point
2) the cost trend of hardware/software dev/maintenance
3) boring/interesting code criterion
...

[brawndo]

I read a blog post about "How to debug RxJS". To summarize: `tap(console.log)`.

[ericbond]

example at 9:50.. Just use a language that is familiar with monads (Haskell do notation/Scala for comprehension)

[ishcatu]

I love this talk, although I don't agree with the defintion of "boring". I am happy to deal with with business logic that is really exciting and challenging. I am even more happy, if I can read domain code without technical details though. Emphasizing the importance of domain logic should never be underrated and domain logic should not be hidden accidentally behind technical details.

[LinasNaginionis]

Showing a simple code example with possible NPE is not comparable with reactive version, which is written very badly. Apples vs oranges.

[hellowill]

I disagree with the premise we should write code for the business.
At the end of the day, the business doesn't care about me, they make a dollar for every cent I make.
So I'm not going to be bored but rather write code I think is interesting and learn as many frameworks as I can.
Writing boring code hinders creativity and fun.

[PecoDanajlovski]

Lessons learned: I am horrible at writing reactive code, therefore I will do 40 minute talk.

[awaken]

9:36 this is why Java reactive code is ugly and barely readable. Im migrating from it to Kotlin coroutines and suspending functions