Thanks, I think I understand your point that coding in Elixir/Phoenix allows us to focus more on code maintainability as the language/framework/OTP handles the scaling etc, but this hasn’t really helped as the general info you’ve provided, I and most noobs already know, and when we read about processes, behaviours, etc, and start to get confident enough to take different approaches, and have delusional goals of building the ‘next big thing’ (which is why I spent weeks researching languages and frameworks before settling on this ecosystem, and before that a few years learning to code other languages, building stuff, and a first startup), and so on.
We want to know as much about how to code for scaling, speed, etc as is possible eg to only use atoms when … because of RAM, how we can scale eg can we have an umbrella app run over multiple FreeBSD servers (and should we?), when to use a plug instead of a function inside a module (because it can take compile time options(?) not just make code easier to read, pipe, etc), and how when should something be an app - because it can be started/shutdown/backed up easily etc - for real world dev ops when the app has grown to be used gloabally.
For example, looking around this forum there are so many scattered Q&As about umbrella apps - asking about practical stuff to use them, their limitations, etc for example, it would be great to have a wiki entry about this stuff - overall architecture - as I’ve tried to explain as a noob.
I really enjoy the clarity/elegance of Elixir and Phoenix, and after learning some Clojure, I’ve come to find that I always have leaned towards functional thinking, but the magic appears to be in the OTP/Beam VM and higher level stuff like GenServer/GenStage, almost as if the messy mutability of OOP has been shifted/‘copied’ to that level from the coding environment and we no longer have to worry about it, but I and others want to build apps that are as popular or more popular than Twitter etc, and to do that, we don’t don’t want to just rely on coding for maintainability but scalability etc too, which means we want to know when to use ‘components’ not just how.
That’s why I asked about those other factors as consideration for when to use a plug etc.