4 ms·

> I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. Easy: as I said down below, you can

> I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. Easy: as I said down below, you can actually get wildly different classes because of things like Hibernate proxies. Also, you guessed it, the dependency injection part. I just hate it. Nothing works together. We have so many hacks and weird work-arounds because something doesn't work. (Websockets not working with tomcat for example, or the many funky troubles with using two modes of authentication at once). > Honestly, I've never run into anyone who considers Spring to be "the bane of their existence", where the real issue wasn't simply that the bulk of their experience was in something else. Where they weren't thrown into someone else's project, and resent working with decisions made by other people, but don't want to either dig in and learn the tech or else search for a new job where they get to make the choices on a greenfield project. In my previous startup, we used python and flask. Something I don't deem scalable for bigger teams/apps. We love Kotlin and Gradle (especially multi-modules). But there are so many drawbacks that just suck time. I have a bunch of private projects, all in Go. Fast and efficient as heck. Nothing I'd like to scale beyond maybe 5 people or 20k loc tho (no idea if bazel or something could help with that, no experience). You get a lot of good stuff, but you gain in fragility with Java/Kotlin. Another point that just comes to mind is: how unsecure is this thing even? Dependencies are ages old, requiring you to litter your gradle build files with work arounds and overwrites so you're secure from some (often critica) vulns.

StevePerkins 3y ago
1. Hibernate isn't even part of Spring. You're free to use a newer ORM like jOOQ if you like, or Spring Data JDBC if you want to get closer to the raw SQL. This gets to what I was saying earlier... usually when I encounter someone with strong opinions on Spring, they haven't really dug in to learn much about it. They don't know where "Java" ends and "Spring" begins, they're just winging it and don't like that this doesn't work out well with larger team projects (arguably with ANY stack). 2. I don't care which programming language or framework you are using. If you hate dependency injection as a general pattern, then every alternative I've ever seen boils down to either: (1) monkeypatching all over the place to achieve the same goals, or else (2) just static hardcoding everything and not writing unit tests with any mocks. I mean, plenty of people utilize one of those approaches. They just usually don't do so while discussing safety and security with a straight face. 2. You cite Python and Go as alternatives, yet immediately acknowledge that they're unsuitable beyond small teams or apps (my God, I'll take dependency issues with Maven Central over PyPI any day of the week!). Honestly, this whole sub-thread seems to boil down to you just preferring to work on small codebases over large codebases. And that's perfectly fine! I just don't think that's language or framework-dependent.
- RamblingCTO 3y ago
  You seem to read what you want to read. I was agreeing with you on the benefits of Java/Spring while still disliking it, citing my experience with go and python. Your only argument is that if this stack makes problems, you just haven't read enough and must be an idiot winging it. The truth is that this whole thing, especially the standard spring stack including hibernate, is just one big footgun. You can't isolate any of these, as this stack intertwines to achieve this level of footgun concentration. Some faults are hibernate, some spring's, some is due to DI, and some are due to java. And I'm fed up with the level of trickery we need to have to work with this without issues. I'd like to focus on the bugs and shitty architecture I introduce instead of others. > (1) monkeypatching all over the place to achieve the same goals, or else (2) just static hardcoding everything and not writing unit tests with any mocks. I mean, plenty of people utilize one of those approaches. They just usually don't do so while discussing safety and security with a straight face. These are both stupid things to do in general. If you do proper hexagonal architecture you need neither of these hacks.
  - StevePerkins 3y ago
    > "I was agreeing with you on the benefits of Java/Spring while still disliking it..." Very well. You seemed to saying that Spring was far less attractive than some unnamed alternative, and I was trying to say that I don't see any such alternative in the same space. If you're basically saying, "Yeah, that's probably true, but I want to vent a little anyway", then fair enough. I will however point out that Spring and Hibernate, etc are NOT tightly-coupled. You absolutely do not have to use any particular database persistence library with Spring, or any particular message bus framework or anything else. If you want to use jOOQ or MyBatis or raw JDBC or anything else, go nuts. The fact that most people gravitate toward certain de facto defaults doesn't make those requirements whatsoever. > "If you do proper hexagonal architecture you need neither of these hacks." I remember seeing that buzzword 15 or so years ago. From a glance at Wikipedia, this seems to be from the "Agile Manifesto" guy. It looks like most or all of this has been absorbed into 12-factor or microservices architecture or what have you. Regardless, I'd be surprised if it truly obviates the need for unit tests.
sublimefire 3y ago
This sounds a bit negative but at the same time not purely related to Spring but rather to the choices of external dependencies. I've worked using Spring for years and it makes me smile reading it. Hibernate looks easy but the abstractions have a cost associated with using and maintaining it. There are a lot of settings you need to get right. There were dedicated DBAs that would optimize it in the past. You could just use JPA to make the life simpler. Tomcat.. I mean why? It was great but I'd say it maybe went out of pace compared to everything else. Why not embedded Jetty. At this point I'm starting to have doubts about how you deploy the services to begin with. Dependency injection is actually great albeit the usual problem is that you need to read books to understand it as there is more than one way to do everything. My pain point was usually related to the differences you need to do among Java, Groovy, Kotlin but otherwise it is awesome. Flask is shite, basic, Python has a hard time solving its mess with dependencies and its multithreading support is meh. Go is great I love it. But if you want to create enterprise software, Java ecosystem has you covered and the engineers are cheaper to hire.
- RamblingCTO 3y ago
  Yeah, I'm also heavily ranting. My nick is meant as a hint haha. In the end and after quite a few years we're almost at a point where we love to work with our stack, minus the occasional weird funky thing happening because of the ecosystem (which would never happen in something like Go for example!). Hexagonal + Kotlin + Gradle multi-modules is a beast! > My pain point was usually related to the differences you need to do among Java, Groovy, Kotlin but otherwise it is awesome. Yup, agreed! We got to run kotlin pretty nice and got to play it together nicely with gradle convention plugins. Agreed on Python. Was my first properly learned language back in the days and my first backend lang. Absolutely annoying. I also love go, but it lacks something like gradle, especially multi-module support. I love it but don't see it on a scale as our Kotlin codebase. > engineers are cheaper to hire I think there's also the benefit of an exotic language. You might only get 10 CVs, but you could probably hire half of them because only passionate people bother to look into exotic things. With java you have a bigger bandwidth ... which causes a lot of work.

StevePerkins 3y ago

1. Hibernate isn't even part of Spring. You're free to use a newer ORM like jOOQ if you like, or Spring Data JDBC if you want to get closer to the raw SQL. This gets to what I was saying earlier... usually when I encounter someone with strong opinions on Spring, they haven't really dug in to learn much about it. They don't know where "Java" ends and "Spring" begins, they're just winging it and don't like that this doesn't work out well with larger team projects (arguably with ANY stack). 2. I don't care which programming language or framework you are using. If you hate dependency injection as a general pattern, then every alternative I've ever seen boils down to either: (1) monkeypatching all over the place to achieve the same goals, or else (2) just static hardcoding everything and not writing unit tests with any mocks. I mean, plenty of people utilize one of those approaches. They just usually don't do so while discussing safety and security with a straight face. 2. You cite Python and Go as alternatives, yet immediately acknowledge that they're unsuitable beyond small teams or apps (my God, I'll take dependency issues with Maven Central over PyPI any day of the week!). Honestly, this whole sub-thread seems to boil down to you just preferring to work on small codebases over large codebases. And that's perfectly fine! I just don't think that's language or framework-dependent.

RamblingCTO 3y ago
You seem to read what you want to read. I was agreeing with you on the benefits of Java/Spring while still disliking it, citing my experience with go and python. Your only argument is that if this stack makes problems, you just haven't read enough and must be an idiot winging it. The truth is that this whole thing, especially the standard spring stack including hibernate, is just one big footgun. You can't isolate any of these, as this stack intertwines to achieve this level of footgun concentration. Some faults are hibernate, some spring's, some is due to DI, and some are due to java. And I'm fed up with the level of trickery we need to have to work with this without issues. I'd like to focus on the bugs and shitty architecture I introduce instead of others. > (1) monkeypatching all over the place to achieve the same goals, or else (2) just static hardcoding everything and not writing unit tests with any mocks. I mean, plenty of people utilize one of those approaches. They just usually don't do so while discussing safety and security with a straight face. These are both stupid things to do in general. If you do proper hexagonal architecture you need neither of these hacks.
- StevePerkins 3y ago
  > "I was agreeing with you on the benefits of Java/Spring while still disliking it..." Very well. You seemed to saying that Spring was far less attractive than some unnamed alternative, and I was trying to say that I don't see any such alternative in the same space. If you're basically saying, "Yeah, that's probably true, but I want to vent a little anyway", then fair enough. I will however point out that Spring and Hibernate, etc are NOT tightly-coupled. You absolutely do not have to use any particular database persistence library with Spring, or any particular message bus framework or anything else. If you want to use jOOQ or MyBatis or raw JDBC or anything else, go nuts. The fact that most people gravitate toward certain de facto defaults doesn't make those requirements whatsoever. > "If you do proper hexagonal architecture you need neither of these hacks." I remember seeing that buzzword 15 or so years ago. From a glance at Wikipedia, this seems to be from the "Agile Manifesto" guy. It looks like most or all of this has been absorbed into 12-factor or microservices architecture or what have you. Regardless, I'd be surprised if it truly obviates the need for unit tests.

sublimefire 3y ago

This sounds a bit negative but at the same time not purely related to Spring but rather to the choices of external dependencies. I've worked using Spring for years and it makes me smile reading it. Hibernate looks easy but the abstractions have a cost associated with using and maintaining it. There are a lot of settings you need to get right. There were dedicated DBAs that would optimize it in the past. You could just use JPA to make the life simpler. Tomcat.. I mean why? It was great but I'd say it maybe went out of pace compared to everything else. Why not embedded Jetty. At this point I'm starting to have doubts about how you deploy the services to begin with. Dependency injection is actually great albeit the usual problem is that you need to read books to understand it as there is more than one way to do everything. My pain point was usually related to the differences you need to do among Java, Groovy, Kotlin but otherwise it is awesome. Flask is shite, basic, Python has a hard time solving its mess with dependencies and its multithreading support is meh. Go is great I love it. But if you want to create enterprise software, Java ecosystem has you covered and the engineers are cheaper to hire.

RamblingCTO 3y ago
Yeah, I'm also heavily ranting. My nick is meant as a hint haha. In the end and after quite a few years we're almost at a point where we love to work with our stack, minus the occasional weird funky thing happening because of the ecosystem (which would never happen in something like Go for example!). Hexagonal + Kotlin + Gradle multi-modules is a beast! > My pain point was usually related to the differences you need to do among Java, Groovy, Kotlin but otherwise it is awesome. Yup, agreed! We got to run kotlin pretty nice and got to play it together nicely with gradle convention plugins. Agreed on Python. Was my first properly learned language back in the days and my first backend lang. Absolutely annoying. I also love go, but it lacks something like gradle, especially multi-module support. I love it but don't see it on a scale as our Kotlin codebase. > engineers are cheaper to hire I think there's also the benefit of an exotic language. You might only get 10 CVs, but you could probably hire half of them because only passionate people bother to look into exotic things. With java you have a bigger bandwidth ... which causes a lot of work.