Most setups will likely stream both code and assets to wherever the game is running while you're developing as well, but I wouldn't necessarily call that trivial. Recompiling a shared library and hot reloading it if it's changed is (on the order of 20 or so lines), though, and I wouldn't expect any game to be developed without at least some code being reloaded this way.
While I haven't seen it as much, developing servers this way is also very doable, depending on how much you have to change data structures that have to be kept around.
Edit:
See https://www.youtube.com/watch?v=WMSBRk5WG58 for an example of how trivial it is to get this using just your OS facilities (`stat` + `LoadLibrary`/`dlopen`). None of this stuff is new and it's certainly been used with C/C++ or any language like it for a very, very long time.
I don't understand what's happening here. I asked for examples. I get in return two replies that have no examples and barely make sense in context.
Do you have examples of what you said?
I sent you a video of someone doing this in less than 2 hours without even using non-OS dependencies. It's an example of someone actually doing it and showing how trivial it is to dynamically reload code when it changes in statically typed, ahead-of-time compiled languages, a class of languages you claimed don't have hot reloading of code without "complicated IDEs".
Usually you would want to hot reload the code sections though and allow the application to change the data section which is significantly more intuitive than changing source code to change data.
Edit:
On that note most game engines serialise state to disk, pretty sure it would be easy to just read the state from like a yaml file and update the state if you really don't want to write an interface.
TLDR: There are significantly easier solutions to "how do I update the value of a variable at runtime" than hooking into the running process and changing the variable in memory.
