Init functions seem to be a good way of iniitalizing package level variables, the developer doesn't need to call them (saves boiler plate writing on setup and later on when you want to wire something up) as the flow of calls is implicit based on the package import dependency graph. Since the developer has to understand this graph anyway for organizing packages, it doesn't add anything extra to learn about the project.
Package level variables can be imported directly and used without needing to append to an existing struct, this is pretty convient for things like healthy reporting external errors because adding this client to every model, gets tedious.
I originally though overlapping variable names would become an issue since we are dealing with package level scope variables, but there are very few of them and the names are pretty standard and unique just like standard library names (e.g., config, database)
In MVC most objects are represented as singletons, so having them exist as package variables makes a lot of sense since there will be a very limited number of exported variables to begin with. Also encasulation further than the package level is overrated since it only "enhances" developer experience when using an LSP rather than actually contributing to faster build times or anything.
Can choose with init functions to include in the build, which is useful for not triggering things like connecting to your database when all you want to do is run some unit tests.
Panic is useful for initilation errors because bubbling up the error to the main function doesn't add much value since the only thing we want to do during init failure is crash the application and give context on the crash to the developer (stack trace is very nice here). We want to crash because depending on the init stage of the app, we may not be able to do things like trigger an alert/update monitoring because we haven't initialized far enough to reach those tools yet.
There is more property drilling in the case of the config.go file but I think this is a good thing because drilling through properties is locality of behavior, only need to look at two files to see where they are comming from instead of trying to trace a massive chain of constructors. So even though it doesn't "look as neat", its still simpler.
Discovered its slightly better to use inline declaration assignment if no error handeling is required, because it keeps everything together:
var LandingPage = LandingPageView{
view: views.LandingPage,
}
Can navigate to the singleton declarations very easily by string searching with telescope and them typing "var" to filter