3 ms·
I've been banging this drum lately on HN too. Spring Boot makes Java fast, easy, and simple. Yes, you still have to install a JVM on your image, but there are p
by virmundi 9y ago
I've been banging this drum lately on HN too. Spring Boot makes Java fast, easy, and simple. Yes, you still have to install a JVM on your image, but there are plenty of management script out there to get a container or VPS running.
For people out there that look at all those getters and setters with contempt: you don't need them for your JSON objects. Just use public. The frameworks will still serialize and deserialize without issue. Use JSON annotations to define what a valid message is. Yes, you'll need a mapping layer between your JSON/inbound messages and your domain, but you need that anyway, otherwise your API is brittle.
JPA + Spring can lead to fast DB code and development time that rivals NoSQL with Postgres. You can have it autogenerate the DB during dev time with each boot, then create Liquibase migration documents for true devops stability.
After working with Go for a month, I really think Java just does things right. Servlet API is simple. Spring makes it easier. Transactional management + AOP is wonderful. So many cross-cutting concerns allow you to properly encapsulate and apply the logic in a few AOP. You just can't do that with GO without a lot of compiler work.
- jrs95 9y agoPersonally I've had the exact opposite experience with Spring Boot. To me it feels like they've basically had to metaprogram their way out of the limitations of both the language and the underlying APIs which are extremely verbose and obtuse. Every time Spring makes something more convenient, it also removes some static guarantees. Dependency injection issues fail at runtime instead of compile time, but that's not anywhere near the worst of it. Autoconfiguration in particular seems nice at first but can cause all sorts of weird issues. I once had a situation where we added RabbitMQ, and some other JAR started trying to bind to a queue that didn't exist, but the framework was swallowing that exception and it took hours of screwing around in the debugger to figure out what was going on. That sort of thing simply doesn't happen with Go in my experience. Or probably Dropwizard, honestly.