Spring version:

  var records = jdbcClient
     .sql("select * from posts")
     .query(Post.class)
     .toList();
     
  records.forEach(p -> ...);

I'm not seeing a RecordsRequestFactoryHandlerProviderFactory in there... maybe it's not as bad as I remember.

Half of those are not really an issue with the annotation and seem a bit contrived.

Thankfully the company that wrote the article has a linter/warning product to help avoid those pitfalls.

I also have 20+ years of experience and haven't seen that type of code either.

I am however struggling to understand an over engineered Rust "micro" service at work. There's no language or framework that is free from this.

Maybe it's because I have not worked in typical enterprise companies?

Spring Boot can be a really quick way to get things done. My current job is not in enterprise, but we use Spring Boot for most of our services, and rarely have issues related to Spring itself. We have micro services handling many transactions per minute and starts up within 10 seconds. The CPU usage is low and decent memory usage, even on the small pod sizes that we use. There are ways to reduce the startup, but we do not have the need. The code is easy to reason about and new hires are productive within a short time.

In my experience, the same enterprise developers will write complex abstractions in any language. If you have a million coders, 500k will by definition write below average code. And if some of them are elevated to tech leads in enterprise companies, they will spread their "style" to others.

This is definitely true... as a mod/admin on EchoJS, can't tell you the number of times I've seen unnecessary IoC/DI libraries created in JS/TS to match the style of Java or C#.

The reality is that as a scripted environment, there are provisions to override dependencies for testability.... so unless you literally need multiple implementations of a given adapter, you don't need a DI/IoC framework and adding one only detracts from your overall solution. I'm a strong believer in that abstractions should mostly serve to hide relative complexity to make the rest of the application easier to reason with.

I'm also a big fan of the first version of anything being done in a scripted language with an emphasis on correct behavior. JS/TS and Python are more adaptable earlier on without committing to Java/C# or even Rust or Go. I understand a desire for homogeny, but that often can hold you back from creating something functional and easy to replace first.