I think it's a minority opinion but for me Spring fills a particular gap.
If I was writing a data analysis system in Python I would write a few modules, probably with some functions and classes, that do the work and are reusable. I'd also write a top level Python script that would configure, connect and then execute the task. In fact I'd write a whole bunch of those scripts for variation.
In Java I could write a class to do the same but then I'd have to compile it. With Spring I can make an XML file that describes the parts and puts them together, and have just one class that asks Spring to make an object and run a method on it. That XML file replaces the top level script and I can do all this without having to write any code to create a configuration system.
I used to work on application servers that used Spring for configuration a lot but I found the people (various) I work(ed) for switched to Guice around 2015 or so and since then that is what I use at work.
Spring and Guice banished the Factoryⁿ, Factoryⁿ⁺ⁱ, Factoryⁿ⁺² problem by introducing a MetaFactory that lives outside the system, understands it globally, and does all the construction for you. Go could probably use something like that but you need to think about how the construction/destruction problem manifests in Go and how to do it in a way that feels right and works right for Go.
If I was writing a data analysis system in Python I would write a few modules, probably with some functions and classes, that do the work and are reusable. I'd also write a top level Python script that would configure, connect and then execute the task. In fact I'd write a whole bunch of those scripts for variation.
In Java I could write a class to do the same but then I'd have to compile it. With Spring I can make an XML file that describes the parts and puts them together, and have just one class that asks Spring to make an object and run a method on it. That XML file replaces the top level script and I can do all this without having to write any code to create a configuration system.
I used to work on application servers that used Spring for configuration a lot but I found the people (various) I work(ed) for switched to Guice around 2015 or so and since then that is what I use at work.
Spring and Guice banished the Factoryⁿ, Factoryⁿ⁺ⁱ, Factoryⁿ⁺² problem by introducing a MetaFactory that lives outside the system, understands it globally, and does all the construction for you. Go could probably use something like that but you need to think about how the construction/destruction problem manifests in Go and how to do it in a way that feels right and works right for Go.