You also have Erlang’s sys module, so with a pid you can do :sys.get_state(pid) and get the actual state, and there’s other functions in sys. You can also always create a specific handler to handle the state inspection (though both sys and handlers require that the server isn’t blocked doing something).
I have no horse in the race between elixir/erlang and other languages and sometimes I wonder looking at the code why I prefer to work with elixir/erlang - but in the end it boils down to the actual simplicity - once you have in mind the very basic building blocks everything more or less follows the same structure (supervisor, children (which usually have more children), monitor/link, trap exits or listen for down messages, start->do stuff in steps->stop) and extending a gen_server, or gen_statem to handle new cases, new flows and/or new paths is usually pretty trivial in my experience - the same with adding concurrency to it, limiting the concurrency, etc. Lastly usually if you’ve isolated the servers, changing them to a new independent app is a matter of moving the modules and changing a few lines in the supervision trees. To me it just makes sense. Of course, some things are expensive to do in the beam but since I usually don’t need super fast arrays or anything like that where mutability shines, I’m ok with that.
