[revskill]

Hacking on Java frameworks is mostly a pain. Both from IDE tooling (too much RAM, configuration fighting,...) to the documentation. Basically it made simple problems harder for just "JAVA" reason.

For comparison, i've spent many months to hack on Java framework in a company before to deliver a hackable feature.

By the same time, i also released 3 production applications from scratch with Rails.

The issue is not Java is impossible to have such productivity, it's the mindset, the culture issues from Enterprisey people.

[pjmlp]

Again, that culture was already there decades before Java came to be, COM, SOM, CORBA, Taligent, ER model, Booch method, Rational Unified Process, Structured systems analysis and design method. Yes, I am an old dog at this game.

Had Ruby and Rails been embraced at the same scale, you can bet there would exist a comparable flavour of Ruby EE.

[revskill]

As i said, it's about the mindset that matters (rather than throwing me a bunch of design patterns).

If you're at work and want to get shit done fast for the salary reason: There's no reason NOT to use Rails.

If you want to go enterprise, use something lightweight and modular, composable instead. Throwing a bunch of inheritable BeanClass serves no purpose on the job.

UNIX philosophy came long ago, before JAVA.

[pjmlp]

UNIX philosophy is cargo cult from a book worshiped by FOSS folks.

CORBA was born on UNIX, original implementation targeted C, C++ and Smalltalk.

Java was years away to be created, again by a UNIX company.

Java EE, was reborn from an canceled Objective-C project created by Sun and NeXTSTEP, again two UNIX companies.

[revskill]

No, unix philosophy is what make things work together as i see. A big mess of inheritance tree doesn't solve large scale problem. That's the misunderstanding of "large scale engineering" that i've seen from most companies.

You don't solve problem by solving it. You solve it by decomposing it, and compose again.

[pjmlp]

The technical architects, solution architects and business analysists couldn't care less about what a worshiped book says about the UNIX philosophy.

On the enterprise mines, the minions do what they say.

[KronisLV]

As someone who has done a lot of "enterprise" Java, I feel your pain.

> The issue is not Java is impossible to have such productivity, it's the mindset, the culture issues from Enterprisey people.

I do think that a lot of it will depend on what sorts of projects people work with, as well as how old the frameworks are. Some design choices made in the development of those will certainly show their age. Consider this article, for some nice arguments in that regard: https://earthly.dev/blog/brown-green-language/ (I'd say this also applies to frameworks, not just languages themselves)

I actually recently used Dropwizard to create a proof of concept system for storing and querying millions of files by their metadata and using Java wasn't too bad in the end: https://blog.kronis.dev/tutorials/1-4-pidgeot-a-system-for-m...

I'd vaguely rank the frameworks and libraries as follows:

  - Java/Jakarta EE: pretty dated at this point, you'll mostly see it in legacy projects, generally not a "modern" feeling experience, if you need to configure a separate web server instead of an executable .jar file, you're going to have a bad time
  - Spring: if you see plain old spring, you'll have a bad time, it's the definition of "enterprise" code and will waste lots of your time
  - Spring Boot: can be good if you start a new project with a recent version, still somewhat enterprise but lots of integrations are just plug & play
  - Dropwizard: takes a bunch of idiomatic Java packages and glues them together, comparatively lightweight, you can even get by without dependency injection, most of the cruft that you need to deal with ends up being because of the language itself instead of a framework with bunches of weird dynamic class loading and reflection
  - Quarkus/Vert.X/...: new frameworks and libraries that try to build something more modern and performant, generally you can look in the direction of these for many of the modern projects that you want to do, though their lack of maturity might show sometimes (e.g. if you try doing something unsupported, or just run into their learning curve, e.g. how the Vert.X event loop works)

I guess I can sum up my thoughts with:

  Is Java as a language inherently a bit more annoying to work with than some of the other web dev languages? Definitely.
  Have its frameworks and the language itself gotten better in the past years, especially after newer versions than Java 8 came out? Yes.
  Are many out there going to pick it for its decent static type system, good runtime performance (JVM is great) or bunches of stable packages? Sure.
  Are some going to be pigeonholed into working with horrible legacy projects that are absolutely demotivating and show off the worst of the language? Sadly, also yes.
  Are others going to look in the direction of something like Kotlin, which attempts to solve some of its nuisances, or maybe other languages altogether? Also yes.

But at the end of the day, a lot of it comes down to familiarity: if you feel like you'll be more productive in .NET, Node, Ruby, Python or another language, and there aren't external external factors that force your hand in a particular direction, pick whatever fits your needs the best.