[liampulles]

Different strokes I guess. I've previously worked at big orgs. with Spring, now working with Go microservices and enjoying it by and large.

I don't miss the days where I had to deal with random missing or conflicting beans stopping my app from starting. The nice things about a Go app is because the control flow is so exposed, if it compiles you can be pretty sure it is going to run, and if it doesn't compile you can go to the red in your IDE and fix it.

Adding an endpoint is a matter of updating our OpenAPI file and doing `make oapi-gen` for the code generator we use. I think this is a similar level of effort to doing the same with a mvn or gradle command.

The real difference I notice between Go and Spring microservices though is how much easier it is to dev and debug multiple microservices - it is trivial to compile all of our Go microservices and boot some of them up for debugging without eating all of my laptop's RAM, which is especially relevant if I also want to run them in Kubernetes locally.

I will say I do miss some of the niceties of aspect oriented programming with Spring.

[cnity]

By far my least favourite thing about the Java web ecosystem is how weirdly obscured the bootstrapping process for starting processes is. So much of how your application starts is determined by XML files and DI frameworks that I often have no idea (or am sometimes not even exposed to) where the `main` function is.

[kaba0]

I’m only assuming, but I guess your last experience with Java is a bit dated, XML configurations have been largely replaced.

And then what we are left with is a huge, old project vs some new microservice, which would be an unfair comparison in any language

[cnity]

You're totally right. I'm sure things are better now in modern Java and adjacent spheres like Kotlin.

[jcelerier]

Caring about the main function in a framework-ey app generally makes as much sense as caring about the x86 initial boot code when launching mspaint.exe

[cnity]

Not for newcomers to the codebase. Approaching an application that is forced to make the entire application clear as day (as in Go) is so much easier than such Java codebases because I can just read the code and see what it does. This is just my experience though. The Java codebases are always fine as long as I have read several pages of documentation first, which I've learned to do for those cases.

[digianarchist]

I've seen devs write caches that were shared between customers because they didn't understand the lifecycle of Spring Autowired dependencies.

Understanding how the framework wires things together is important.