Thank for such a long and very detailed comment. I'll try to explain our design goals.
I think the main difference is that mortar is heavily based on Dependency Injection (uber.Fx) and this affects a lot.
If you want you can have multiple instance of the Logger interface, just 'name' the instance and FX will help you inject the one you like. https://godoc.org/go.uber.org/fx#Annotated
This makes it's extremely easy to inject any instance anywhere you like.
This allows to partially configure any concrete implementation ahead of time, say in some company-platform library and the developer will only need to "Build" it in the final project or adjust parameters if needed.
This project is actually a second version of an internal project we created at Here Mobility, eventually this design helped us to increase developer velocity by introducing
- a unified project structure
- devops preconfigured libraries to help integrate the services within our internal cloud setup
- we had several groups and each had more than one products with backends so we needed to allow every group to develop the way they wanted, but at the same time maintain company standards and devops practices. It's not easy to make sure all your company services are aligned to the same versions unless you work on top of mono repo and we didn't.
Mortar design goal was some what a compromise to allow customization but if not a good and reliable standard.
What is not mentioned on the main page is the Builder approach we use https://github.com/go-masonry/mortar/blob/master/wiki/builde...
This allows to partially configure any concrete implementation ahead of time, say in some company-platform library and the developer will only need to "Build" it in the final project or adjust parameters if needed.
This project is actually a second version of an internal project we created at Here Mobility, eventually this design helped us to increase developer velocity by introducing - a unified project structure - devops preconfigured libraries to help integrate the services within our internal cloud setup - we had several groups and each had more than one products with backends so we needed to allow every group to develop the way they wanted, but at the same time maintain company standards and devops practices. It's not easy to make sure all your company services are aligned to the same versions unless you work on top of mono repo and we didn't. Mortar design goal was some what a compromise to allow customization but if not a good and reliable standard.