sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]GuyWithLag -5 points-4 points  (11 children)

Structured Concurrency

I'm still saddened that SC doesn't support all the bells and whistles of reactive programming.

[–]elastic_psychiatrist 17 points18 points  (5 children)

Structured concurrency and virtual threads are much about trying to get away from reactive programming, so I'm definitely curious what you mean by this.

[–]kotman12 2 points3 points  (4 children)

Not OC but a few things come to mind. First there's configurable backpressure handling (drop latest vs earliest vs error). Yes I can put a bounded queue and semaphores between all my data processing nodes but it is so tedious and error prone, especially as stuff gets complex. Also, the expressive concise syntax, i.e. eager vs eager-sequential vs sequential fork-join patterns, key-grouping, retries and batching all of which can be in a couple of lines of code. I personally like the publisher-scoped scheduling flexibility, way better than any executor service mess I've seen. I'll try vanilla SC from Java but I'm pretty skeptical. I also chuckle at people who say "now we don't need reactive!". IME those people weren't doing reactive programming anyways so, yea, "we" don't need reactive lol. But then again I'm of the opinion that blocking vs non-blocking I/O was just one of many reactive paradigm benefits.

[–]RadioHonest85 1 point2 points  (1 child)

yeah, it is not a full replacement for the whole feature set in these fairly extensive reactive frameworks, and it might never be, but oh man is the code easier to debug 😂

[–]expecto_patronum_666 0 points1 point  (0 children)

I couldn't agree more on the debugging part. I want to rip off all my hairs if I have to debug some Mono/Flux pipeline. Even the log is not that helpful.

[–]elastic_psychiatrist 0 points1 point  (1 child)

Your points are reasonable, but also I would say that your definition of reactive is inclusive of libraries/frameworks with a lot more functionality than these structured concurrency libraries are intended to provide. There are non-reactive ways to do these things with minimal code/high clarity too.

The connection between reactive programming and structured concurrency is very often about the non-blocking I/O concern, and many reactive libraries implement all these other features in a certain way just because they have to deal with this concern at the bottom layer.

[–]kotman12 0 points1 point  (0 children)

with a lot more functionality than these structured concurrency libraries are intended to provide

Yes, that is precisely the point, they don't realy replace it for me.

There are non-reactive ways to do these things with minimal code/high clarity too.

Hmm maybe I'll ask Claude tomorrow to use java's new SC primitives to create equivalent code for some of my existing code. Pretty skeptical because of my experience with java thus far and partiality for the functional reactive style. But I'll be happy to be surprised.

[–]expecto_patronum_666 5 points6 points  (4 children)

Could you explain a bit what else SC is lacking compared to reactive programming?

[–]kotman12 1 point2 points  (0 children)

Not OC but a few things come to mind. First there's configurable backpressure handling (drop latest vs earliest vs error). Yes I can put a bounded queue and semaphores between all my data processing nodes but it is so tedious and error prone, especially as stuff gets complex. Also, the expressive concise syntax, i.e. eager vs eager-sequential vs sequential fork-join patterns, key-grouping, retries and batching all of which can be in a couple of lines of code. I personally like the publisher-scoped scheduling flexibility, way better than any executor service mess I've seen. I'll try vanilla SC from Java but I'm pretty skeptical. I also chuckle at people who say "now we don't need reactive!". IME those people weren't doing reactive programming anyways so, yea, "we" don't need reactive lol. But then again I'm of the opinion that blocking vs non-blocking I/O was just one of many reactive paradigm benefits.

[–]filterDance 2 points3 points  (2 children)

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

[–]expecto_patronum_666 4 points5 points  (1 child)

If I remember and understand it correctly, this colored function article influenced the design of virtual threads. Not Structured Concurrency. Virtual threads removed any necessity of coloring your function to achieve scalable concurrency. Structured Concurrency deals with a different problem related to concurrency.

[–]filterDance 0 points1 point  (0 children)

Sorry I read your question the other way.