The JVM doesn’t need this kind of thing either, and it gets a bad wrap from the J(2)EE days, and the “simple” replacement that Spring was supposed to be.
No doubt there’s some benefits to be had, but I don’t think the trade-offs are worth it, especially at larger scales.
Just rewrote it in Go. Now we are using a server which consumes 30% of ram what the existing one used to and the latency and throughput have all improved.
Don't use these stupid java backend like sprinboot.
Just rewrite it in X doesn't "just work" for complex systems. It ignores risk, and the fact that design usually matters more than language.
When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight of the actual essence of the problem because they are obsessed with conforming to the framework.
Because the ecosystem and toolchain surrounding Spring Boot and Java are so mature and well-supported, it is very easy to find community tools that make you feel like you are doing things the "right way."
I only realized these issues after I left Spring Boot and Java development behind. Now, I much prefer using TypeScript or Python to write code (for example, web servers).
I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security. I honestly never want to go back to the days of writing Java again.
sidcool•1h ago
fiftyacorn•1h ago
rockyj•53m ago
Now read up on all the dozen of annotations. But yeah, we did not want to "re-invent the wheel".
fiftyacorn•32m ago
tonyedgecombe•50m ago
sidcool•31m ago
__alexs•5m ago
geodel•46m ago
Usage being high doesn't say anything about quality or suitability of a product specially in enterprise settings.
nilamo•21m ago