Tangentially related I hope developers will realize that the current stack inherited from them is basically enterprise software made for large teams of interchangeable developers, just with better marketing than J2EE 15 years ago.
> I believe that if there was a full standard distribution for Java EE (e.g. Icefaces+JSF+Seam+EJB3+JPA+Hibernate+Glassfish, to name just one possible API stack out of thousands of different combinations), people would write a lot more good documentation for that particular stack, and it would become a lot easier for more developers to start using it effectively. With the right tools and good documentation, productivity could potentially be about the same for Rails and Java, but at the moment Java is shooting itself in the foot in this regard.
I would have to agree with this -- I work with a lot of large telecoms and nearly all of them use Java for any back-end services that need scale. Sure, Java is insanely verbose syntactically; but that has the side-effect of forcing you to formally model your application architecture in order to generate stub code. The unfriendliness of Java is just managed through tooling that presents a simplified interface to developers. It's easy enough to wrap a JVM in a container to work with Kubernetes or arbitrary cloud services, so many of the operational aspects of working with the JVM are greatly simplified.
Moreover, Java on the web (first in the form of JSPs, later Spring-based frameworks) was largely a reaction the shortcomings of LAMP, which was largely a reaction to the shortcomings of Perl5 CGI-BIN (what I consider to be the first widely-used web framework). The great irony is that Perl had an advanced dependency management system in CPAN in the mid-1990s and PHP had nothing for years. Ruby on Rails succeeded largely by combining a CPAN-like dependency management system with a web-native development framework.
You must be joking. A good Rails dev will run absolute rings around any java or .NET effort no matter what tools they're using. I don't even think I'm being subjective here; I work with java (well, kotlin/scala) devs and even they wouldn't say anything like that.
Rails has disadvantages yes, concurrency and its lack of ability to support long-running tasks foremost amongst them, IMO. But dev speed, for standard "startup web app" features? There is no contest and I'm baffled as to why you would claim otherwise.
There are few technologies I despise more than Spring. Well, maybe OSGi. Also, hibernate and JPA. I've lost so many hours of my life fighting those things.
I try to stick to Clojure for most of my JVM-ing these days. Right now I've got this one large Java/Spring-boot service I've inherited sitting in the middle of an otherwise micro-services-based architecture built using Clojure/ring and Python/flask services (for the ML stuff). I keep thinking about how I want to start calving off chunks of that thing to re-implement in something not Java/Spring.
Because Spring magic is great until it's not. And then you're banging your head against your desk for a week chasing down some weird heisenbug related to some nonsensical Spring behavior. And there's no sense of accomplishment when you finally resolve it, because the entire exercise only served to increase your esoteric knowledge of Spring, which you never wanted to deal with in the first place.
For reference: https://martin.kleppmann.com/2008/05/11/ruby-on-rails-vs-jav...
> I believe that if there was a full standard distribution for Java EE (e.g. Icefaces+JSF+Seam+EJB3+JPA+Hibernate+Glassfish, to name just one possible API stack out of thousands of different combinations), people would write a lot more good documentation for that particular stack, and it would become a lot easier for more developers to start using it effectively. With the right tools and good documentation, productivity could potentially be about the same for Rails and Java, but at the moment Java is shooting itself in the foot in this regard.