If i'm not mistaken, ReactiveX was created by Microsoft for their .NET platform before it reaches Java and the JVM. They already had the async feature in .NET so, why did they create ReactiveX then if it's perfectly replace able by async?
3 weeks ago
Anonymous
because there's too much coursera coders who don't know about Gang of Four book and can't learn standard patterns
using Rx is the same as writing in Perl, you write it once and then no one understands how it works
especially it's nightmare to debug this shit
3 weeks ago
Anonymous
I dont get it. Async is easier than Rx. Dotnet had async. Microsoft felt the need to create Rx for their projects. So... They did it so that their software can be less readable and maintainable...?
3 weeks ago
Anonymous
rx makes it easier to implement patterns where you need to immediately react on data changes
I see it used a lot for UI such as Control <-> Model bindings
so you don't need to implement Observer yourself, you can just write 2 lines of Rx and your shitty UI is now actually doing something
but it comes with making your code:
1. unpredictable
2. unreadable
3. undebuggable
so fuck rx and microsoft too
every fucking intern tries to sneak this crap in my codebase, and I have to teach them about the gang of four book
3 weeks ago
Anonymous
What is that gang of four book? What principles does it teach?
3 weeks ago
Anonymous
https://en.wikipedia.org/wiki/Design_Patterns
3 weeks ago
Anonymous
So it's only good for UIs and not for the application/business model layer?
3 weeks ago
Anonymous
there's zero need for it in the model layer
it will reduce the amount of code in UI layer you need to write, but at the expense of the mentioned downsides
different teams may treat severity of those downsides differently, but I would argue they are fatal
3 weeks ago
Anonymous
>but I would argue they are fatal
Aren't you exaggerating a bit?
3 weeks ago
Anonymous
>it will reduce the amount of code in UI layer
More so than simple async?
3 weeks ago
Anonymous
never saw or used async for ui, so I can't say much here
3 weeks ago
Anonymous
>never saw or used async for ui
Wat... How is that even possible in the Javascript world. In 2022
3 weeks ago
Anonymous
I write real software, not web crap
3 weeks ago
Anonymous
I understand. But even people who aren't webshitters will eventually have to do webshit at some point in time and deal with JS.
3 weeks ago
Anonymous
sad but true, I hope I'll be dead by then
3 weeks ago
Anonymous
Or that WASM will become a standard by then.
3 weeks ago
Anonymous
>1. unpredictable >2. unreadable >3. undebuggable
Quite literally the opposite of these things. I'm rather stunned to read these experiences. I've basically been using RX heavily in .NET land in my projects for maybe 10 years now and it's been tremendous for the kind of work I do.
3 weeks ago
Anonymous
What kind of app is it? A Desktop Client or server? How do you use Rx and what for?
3 weeks ago
Anonymous
Typically desktop and mobile apps. There's a rather popular desktop I've used RX quite extensively in. I don't think I've used it in anything on a server. It's very useful when there's multiple sources of state you need to be able to respond to in a single block on code.
3 weeks ago
Anonymous
>It's very useful when there's multiple sources of state you need to be able to respond to in a single block on code.
Like... A provider...?
3 weeks ago
Anonymous
why would I want to use a provider if I can just add a new 1000-APIs library and use an entirely new paradigm to solve that???
3 weeks ago
Anonymous
I'm confused... Why would i want to do what you describe instead of using a provider?
3 weeks ago
Anonymous
exactly
3 weeks ago
Anonymous
>Microsoft >They did it so that their software can be less readable and maintainable...?
kek, who would've thought
3 weeks ago
Anonymous
Async and Rx are not the same thing. If Rx is to Async what Collections are to Objects.
Rx let you among other things, treat a stream of events as if it is a collection, and perform useful functional transformations on them. It can be extremely powerful.
3 weeks ago
Anonymous
>It can be extremely powerful.
How
3 weeks ago
Anonymous
Really good at giving a functional way of dealing with changing state. Especially in UI stuff, if you need the UI to reflect the rather complex state information. RX gives you really nice ways of combining different sources of state, and processing them in a way that's clean, readable and avoid mutation.
It's not like there's no down sides, but there's a lot of upsides. There's been many projects I've used this where I feel confident about avoid 10s of hours of testing and fixing lots use obscure edge cases, because of how RX lets me make code that is very readable with regards to how it will respond to all possible state the program could be in.
it may be fine if you're the only one who write and maintain rx-infected codebase
but if you're a part of a team, then maintainability should be your top priority unless you're working for a startup which will die after launch
Idiotic piece of shit, that could be replaced by programming in a functional way.
Angular uses it as it's chage detection. Well I have never seen an angular app that doesn't have memory leaks, is predictive and is easy to test.
Use async/await and if data chages, use functions for that.
..
Not useful. Im dying.
>Im dying
Why?
>Not useful
Then what is the more appropriate alternative?
mobx
What's that and why/hoe is it better than Rx?
.
I hate this over engineered bullshit
It's too complicated for my small brain and balls
Then what's the proper alternative?
depends what you use it for
for model layer either futures or async
for ui layer just standard patterns like delegation or oberver
Is async really an alternative to Rx???
you don't need Rx, especially if you have async
Rx doesn't bring enough benefits with all of its compexity
If i'm not mistaken, ReactiveX was created by Microsoft for their .NET platform before it reaches Java and the JVM. They already had the async feature in .NET so, why did they create ReactiveX then if it's perfectly replace able by async?
because there's too much coursera coders who don't know about Gang of Four book and can't learn standard patterns
using Rx is the same as writing in Perl, you write it once and then no one understands how it works
especially it's nightmare to debug this shit
I dont get it. Async is easier than Rx. Dotnet had async. Microsoft felt the need to create Rx for their projects. So... They did it so that their software can be less readable and maintainable...?
rx makes it easier to implement patterns where you need to immediately react on data changes
I see it used a lot for UI such as Control <-> Model bindings
so you don't need to implement Observer yourself, you can just write 2 lines of Rx and your shitty UI is now actually doing something
but it comes with making your code:
1. unpredictable
2. unreadable
3. undebuggable
so fuck rx and microsoft too
every fucking intern tries to sneak this crap in my codebase, and I have to teach them about the gang of four book
What is that gang of four book? What principles does it teach?
https://en.wikipedia.org/wiki/Design_Patterns
So it's only good for UIs and not for the application/business model layer?
there's zero need for it in the model layer
it will reduce the amount of code in UI layer you need to write, but at the expense of the mentioned downsides
different teams may treat severity of those downsides differently, but I would argue they are fatal
>but I would argue they are fatal
Aren't you exaggerating a bit?
>it will reduce the amount of code in UI layer
More so than simple async?
never saw or used async for ui, so I can't say much here
>never saw or used async for ui
Wat... How is that even possible in the Javascript world. In 2022
I write real software, not web crap
I understand. But even people who aren't webshitters will eventually have to do webshit at some point in time and deal with JS.
sad but true, I hope I'll be dead by then
Or that WASM will become a standard by then.
>1. unpredictable
>2. unreadable
>3. undebuggable
Quite literally the opposite of these things. I'm rather stunned to read these experiences. I've basically been using RX heavily in .NET land in my projects for maybe 10 years now and it's been tremendous for the kind of work I do.
What kind of app is it? A Desktop Client or server? How do you use Rx and what for?
Typically desktop and mobile apps. There's a rather popular desktop I've used RX quite extensively in. I don't think I've used it in anything on a server. It's very useful when there's multiple sources of state you need to be able to respond to in a single block on code.
>It's very useful when there's multiple sources of state you need to be able to respond to in a single block on code.
Like... A provider...?
why would I want to use a provider if I can just add a new 1000-APIs library and use an entirely new paradigm to solve that???
I'm confused... Why would i want to do what you describe instead of using a provider?
exactly
>Microsoft
>They did it so that their software can be less readable and maintainable...?
kek, who would've thought
Async and Rx are not the same thing. If Rx is to Async what Collections are to Objects.
Rx let you among other things, treat a stream of events as if it is a collection, and perform useful functional transformations on them. It can be extremely powerful.
>It can be extremely powerful.
How
Really good at giving a functional way of dealing with changing state. Especially in UI stuff, if you need the UI to reflect the rather complex state information. RX gives you really nice ways of combining different sources of state, and processing them in a way that's clean, readable and avoid mutation.
It's not like there's no down sides, but there's a lot of upsides. There's been many projects I've used this where I feel confident about avoid 10s of hours of testing and fixing lots use obscure edge cases, because of how RX lets me make code that is very readable with regards to how it will respond to all possible state the program could be in.
The observer pattern has been described for eons
No. Rx is great but filters smoothbrains. Async is complimentary to it.
it may be fine if you're the only one who write and maintain rx-infected codebase
but if you're a part of a team, then maintainability should be your top priority unless you're working for a startup which will die after launch
Idiotic piece of shit, that could be replaced by programming in a functional way.
Angular uses it as it's chage detection. Well I have never seen an angular app that doesn't have memory leaks, is predictive and is easy to test.
Use async/await and if data chages, use functions for that.