Client v1.6.0

@dontstealecorock said in Client v1.6.0:

Sounds like you higly increased code complexity in return for nothing.

As a developer that didn't make these changes I can say that subjectively it now feels easier to make changes on the client than before.

@dontstealecorock said in Client v1.6.0:

Sounds like you higly increased code complexity in return for nothing. JVM allocates 1mb per thread. How many parallel blocking request client does? I assume that number is not big. You can even reduce memory per thread using jvm option. 512kb most likely is enough.

I literally cannot answer this seriously without getting sarcastic and rude, so I will not comment on this any further.

I think u can try better. I dont mind if you will be rude(actually your last post is toxic so whats the difference) There should be a reason for switch to non blocking approach so just write it. Maybe u can share perfomance numbers. How many memory blocking code was consuming per call?

Have you even looked at the code before acting so smart here? Or have you just read non-blocking and assumed that complexity went through the roof?

@dontstealecorock
I'd suggest not antagonizing the developers who put a lot of time and effort into working on FAF/related. They've made a lot of good improvements for FAF, and belittling their work like that without actually looking into the details/code first seems counterproductive. Sheikah even linked relevant changes on Github that have further details/explanations/code if you bothered to look through them.

If you truly want to help and have the necessary skills, you could look into the actual code and then take a more collaborative approach.

@dontstealecorock said in Client v1.6.0:

I think u can try better. I dont mind if you will be rude(actually your last post is toxic so whats the difference) There should be a reason for switch to non blocking approach so just write it. Maybe u can share perfomance numbers. How many memory blocking code was consuming per call?

Ok, so here you go:
You take the time to spit out unqualified critics on a topic by reading a short summary of the changes obviously without a) even have the slightest understanding what reactive is about or b) how it affects the client architecture overall. Furthermore if you would have reviewed the changes you would have spotted that this change goes beyond just introducing reactive patterns.

Less memory consumption due to less threads is one of many benefits, but it is not the main driver behind moving to reactive patterns.

I will not argue that in general replacing classic synchronous blocking code with reactive code is increasing the code complexity. I have seen it. I work with it every day. And in some cases it's worth it and in others it's not and I would not introduce it without good arguments.

But that "reactive is complex"-bashing you do here doesn't apply at all, because the client already tries to be asynchronous by applying the crappy Java 8 CompletableFuture logic everywhere it touches API calls. This code was already pretty ugly and complex to understand and using Project Reactor actually can make the code more consistent and easier to read. It also allows additional improvements such as better unit test supports and better handling and mixing of separate async operations than the Java 8 library can.

Furthermore the client by itself is per definition already forced to run stuff in background thread and schedule it elsewhere because it has a GUI with a main thread and we need to be particularly cautious not to ever block this thread. Therefore reactive programming actually is a good match for UI programming which is the reason why web frameworks such as React and Angular was ahead of the Java ecosystem years before (well apart from the fact that JavaScript only allows one thread they needed a better solution).

Looking at actual lobby-server tcp connection: reactive programming here allows us to move away from a constantly polling io thread which eats a lot of CPU waiting (RAM is almost completely irrelevant here). But again this refactoring brought along some other changes and Sheikah can't mention them all along.
We split off the lobby protocol into a dedicated module and wrote it in Kotlin which results in much fewer code. We now have protocol mesage classes with correct null/not-null annotations which makes it easier for future developers to work with it. We tried to decouple the lobby protocol from the client state so we can adapt to protocol changes more easily also enhancing the overall architecture.

Soo essentially we did these changes for different kind of reasons.
You cannot know these reasons. That's completely fine. You can ask for it though and we'd be glad to explain them within our time constraints.
But just picking one argument and bashing on it is just buzzword trolling.

If you’re gonna get mad at a dude being unqualified to give input based on the literal OP and demand he have like 2 years of FAF repo + zulip experience prior to making some criticism maybe don’t make forum threads and keep these updates to zulip where you can get the feedback you want.

Or just lock the thread, because genuinely don’t understand how anything malicious was in that dude’s post.

The point is to let people know what they should be paying attention to when testing the RC so they can give useful feedback.

Like Brutus said, this dude is literally just bashing shit for no reason because he saw some trigger word. It’s a totally pointless comment that does nothing but bash on devs who spend literally thousands of hours of their free time working on this client to make it better, with literally no legitimate basis or knowledge whatsoever. Like you seriously think that you are gonna read the devs 2 sentence layman’s summary and have a better understanding of the problem than the dev who has probably been thinking about and planning for this refactor for several months at least? No. There is no reason to make that comment except to trash talk people.

Imo It is mainly because of this:

higly increased code complexity in return for nothing

Both parts of this statement are extremely bold and backed up by nothing. If he asked some questions about why certain decisions were made that would be fine. Barging in with hot takes is not productive at all.
he then proceeds to give advice on memory limits, seemingly without having done any assessment if the proposed value would even be appropriate.
This whole think makes him look not like a potential developer or an interested player, but like a script kiddie that needs to drop his "cool advice" that he read on the internet. The other option is that it is intentional trolling.

Of course in reality it could be different, but that is my impression from his behaviour.

I mean don’t get me wrong, I have zero clue what any of you are talking about on a technical level so I am not trying to say anyone is right or wrong. I just have a problem with it being an open thread on a forum (meant for communication) and then a dude asks a question based on the information provided and gets lambasted with “I’m not gonna respond until I am” and “pls respect the devs.”

If it’s just informing people for tests, you can still so that with a locked thread. If it is open, I honestly don’t see why the dude can’t post what he did. If it’s a shitpost then why bother responding at all, or just respond with however much effort you feel it is worth. No point in the huge dance.

@blackyps said in Client v1.6.0:

This whole think makes him look not like a potential developer or an interested player, but like a script kiddie that needs to drop his "cool advice" that he read on the internet. The other option is that it is intentional trolling.

Of course in reality it could be different, but that is my impression from his behaviour.

This was my impression too when I read his post. It's just bad form in general to come into here and immediately accuse all the devs hard work as being "for nothing."

If he's legitimately an experienced dev he certainly doesn't have the how to communicate aspect of being an engineer down, and him commenting on JVM thread allocations really does seem like a script kiddie trying to be smart.

I like that this thread is here and that we can post on it, and I am pretty sure that if I came in here and said something like "hey, I know making the app fully non-blocking can add a lot of complexity in some scenarios, did you guys see a lot of improvements from making this change?" I probably wouldn't have been met with the same reception this guy did.

Though I also took a look at the pr and didn't get the feeling that it really made things more complex anyway. Not that me skimming through a 12k line pr in a language I don't use professionally for 5 minutes means much.

Yea exactly. If he was legit trying to be helpful then he would have just asked his question, instead of stating that it was a huge waste of time based on zero knowledge.

And ignoring it as a shitpost is what we did until he came back and asked to be reamed .

I think u can try better. I dont mind if you will be rude

I won't argue about complexity since i don't know the code base. I just saw statement about performance improvement which sounds like it motivates the changes. Its a common way to sell shiny approach by telling it will work faster. So i couldnt resist to throw some shit on it. You seems to be trigered by "waste of time". I probably could write in a more friendly manner but have a little english communication expirence so i just wrote what i have in my mind. In development it happens all the time u do something what is not worth speending time on it. I dont really know was it worth or was not. I didnt give any advice, it was an argument.

If it’s a shitpost then why bother responding at all, or just respond with however much effort you feel it is worth.

His post is specifically triggering for any dev (as you can see) because he knows just enough to create the impression that he knows what he is talking about, specially to new programmers or people potentially interested in contributing.