Hello.
Why not use a system of actors where instead of having one central entity you have multiple entities that pass data between them and act accordingly?
Rust supports this quite well through the use of channels. You could have an actor responsible for networking and an actor that would be responsible for updating the game world. Fundamentally, what's good about actors is that to communicate with them, you just need a public interface, that in this case could be std::sync::mpsc::Sender<T>.So you could just pass events around without the other systems having to worry about each other's state.  I could be missing something obvious here, so please do correct me if that is the case.

@3
By documentation I mean like at least something like `rust doc`, its just a bit disorienting to check file by file because of private vs public and all that, maybe my way of doing it is wrong, not sure, because I view with notepad just view stuff, not sure if vscode has an easy way to do something better?
also I mean third party library documentation, not C# language documentation, yes it's on the author but in rust regardless you can do rust doc to find all the functions, structs, enums etc even if without an explanation.
hmm, not sure how to clarify more? That's basically my issue.
I'm not exactly against threads and async except in rust, because yes, rust made me hate threads lol, I tried once or twice and found it to be way too much for what it is worth, and async in rust is... Interesting, it actually made me think of all async in all languages wrong because I assumed all languages do stuff the same way.
yeah I suppose I was trying not to make the server struct impl become 5000 lines because I really thought of it as messy? Is that a wrong way of looking at things?

@5
yeah exactly, I want to see all public classes, functions, fields, properties, enums, anything, in a list, not for C# itself, while that will also be useful but that can be easily found in the internet from microsoft learn, but third party libraries.

@7
No you misunderstand, I don't mean give me < long tutorial stepb y step for everything >, I mean, give me a list of public functions, classes, fields/properties, enums etc, with an optional explanation, that's just it, I don't need a huge tutorial or step by step guide or anything, and no, not for games, for libraries, for example, someone made an openAL binding? You have an API reference, Bass binding? API reference, JSON parser that is somehow really fast and has a lot of customization options? API reference, that's just about it.

@9
if I understand intelisense correctly it just, displays stuff when you write them? Like auto complete and stuff? I use that. But I mean like, a tree or web page or something, like docs.rs's system of displaying API documentation, is there a way to do that with vscode?

I'm sure C# has at least one documentation generator but I don't believe it is as standardized. Same problem with Python, JS, etc.  You are learning about how whoever makes the most recent language gets to solve packaging.  Rust was the last popular one, so they got a bunch of things right, and whatever comes next will get a bunch more things right and then we will be sad we are in Rust.  One of the things Rust got right is Rustdoc being standard and easy to use.  Python sort of tried, but sphinx is...special.

You don't know what you're doing, so if you stay in Rust thousands of lines for the server is better than trying to violate safety with global statics, and it at least works.  Note that you can split impl blocks between files, though.  It doesn't have to be a thousands-of-lines file, you can still organize the code well.  There are better ways to solve the problem that aren't tons of methods on a top-level object but they are hard to put into words and boil down to Rust being for the intermediate to advanced coder.

In general the insight is just figuring out how to split things the right way.  You're trying to move data "down", but in any good program in any language data should mostly move "up".  I don't have better words.  What makes a good module or whatever though is that you can look at it by itself and it doesn't really necessarily need you to know about the whole app or all the fields on the server or whatever.  Like for example maybe you make a PlayerManager, but that requires that players need a specific subset only, so you have to figure that out.  The difficulty with Rust is that the mutability rules indirectly enforce doing this well.

But seriously go read the bevy tutorial or something.  The entity component system libraries solve this for you.  They add complexity, but they're hard to use wrong and they don't run you into the mutable borrow meatgrinder.

As for Rust async, async in other languages is mostly the same save that Rust natively supports cancellation.  The issue with Rust async is that it takes your mutable borrows issues and multiplies them by 10 plus a side of understanding Pin and Unpin.  I have seen very experienced coders who have done C/C++ for a decade run into Pin and Unpin like crashing into a brick wall.  They got over it in a couple days because, you know, decade plus it was at work where you've got a whole workday to figure things out, but...well, if someone that experienced has trouble I hesitate to throw newbies at it for anything beyond  basic networking where all your questions can either be answered or end at "just throw Box around it".  Trying to figure out how to repurpose an async executor to let you use actors for everything is not worth it to me because you have to bend things until they break, and for you it means learning a whole lot and then bending things until they break.  But also I haven't seen anyone seriously use actors for anything since akka/scala a decade ago except maybe the occasional HTTP server and the Erlang ecosystem (Erlang is a niche programming language).