For the majority of my career I haven't worked on greenfield projects. I've been debugging, modifying, and otherwise maintaining pre-existing projects. As a result I've grown to really dislike frameworks that autowire things together. The very same features that made it easy to get started make them harder to maintain going forward. It turns out following the code in your own codebase is easier than following the code in the framework.

Django isn't as bad as some in this respect, (cough, spring, cough), but it still exhibits some of the same issues regarding maintainability. Go front-loads some work so that longer term maintenance is easier. And the vast majority of code work is maintenance not greenfield development.

Just my personal anecdote, but I recently had to port the backend of one of my pet projects away from ruby due to performance issues - parsing around 50MB of string in ruby isn't an amazing idea.

So I figured the natural choices there would be go because it's new and in demand, and java because I have a couple years of java se experience.

So, figured, let's evaluate java... and I just failed to comprehend the spring stack just from googled tutorials. There's such a dense layer of magic going on in there, I'd either need to not understand most of my stack, or spend weeks and weeks reading and understanding.

Yeah, Spring is one of the worst offenders I've seen. At my current job I'm working on code written with Spring and debugging takes probably 5 times as long as it should.

Reading your comment reminded me of this great talk by Christin Gorman about maintainable code:

https://vimeo.com/138774243

(Jump to 25:50 for an anecdote about maintaining a "well engineered" system)

Oh my goodness. She totally captured my career in a nutshell. There is nothing quite like running into an interface while you are trying to trace a problem. Your head just immediately hits the desk and then you go looking for aspirin.