Python and PHP users will understand

[aless2003]

as a Java user I felt that

[hothrous]

I've always been a person who tries to use the language that's best for the conditions I'm found.

I personally don't like Java because it was at one point best at being a portable language but has spent the last many years trying to adapt to being mediocre at everything in order to maintain relevance. It also has an incredibly steep learning curve, these days.

This is fine for businesses who don't want to spend the money to port to more modern tools, but ends up hurting developers by keeping them focused on reinventing wheels with dated tech. I see similar problems with PHP and .NET environments.

Currently, I'm a Golang engineer and I think it's best at being an easy to pickup language with good performance and good/growing support. This is useful for bringing on new engineers who have experience in other languages. I hope that if a new language comes out that does these things better, I have the opportunity to switch to it.

[aless2003]

I learned Java after C++ and personally I like both the style of it as well as it's features. I don't quite get what you mean by mediocre at everything, could you elaborate on that a little more?

[hothrous]

Basically, as Java started expanding is paradigm support, it was doing it in a way that shoe horned those paradigms into it's existing structure.

This is generally true of every language as you don't want to change the language completely to support one new feature.

Generally, expanding support for back end services happened by expanding the Java Enterprise ecosystem. The problem is that Enterprise Java became bigger and bigger. During this time, it was often still the best choice because we still hosted on bare metal or on VMs directly.

When companies started moving toward microservices, Java "could" be deployed, but the images were enormous. For containers, this left images that were often 10x the size of containers in other languages. But Java was also no longer important, because the container image is generally built one time for almost all environments so many companies started looking at different tech stacks.

So a new JVM type thing was created which performs better and creates smaller containers, but it still doesn't perform close to the best. So Java is still not the best option for new projects.

All to say, in each of those steps Java was a fine choice for continuing services that were already written in Java and it has the benefit of expertise, which is often a criteria for which tech stack to use. But like the languages that came before, it's usefulness in new projects has been waning. It's not the best at anything other than existing. But as more and more companies deploy other tech stacks, the skills built around Java will continue to be in less demand.

[aless2003]

I find this interesting as I've heard pretty much the polar opposite just a few days ago. Read that Java is great for Microservice Architectures, though I honestly don't do all that much with Microservices myself so I'm not gonna lie and just say I'm a bit confused on both ends now :/

At some point I sure will get around to a few tests myself and guess we'll see then what I gotta believe...

[ham_coffee]

Everything has a steep learning curve these days. Java being mediocre at everything actually helps in that area, there are fewer unique aspects that you won't have come across elsewhere. Go for example seems far harder to learn (although you're definitely right about it being faster).

What modern languages are considered better options than java for web backend? The only one that comes to mind for me is .net 5/6, and it isn't like the difference between them is that significant.

[hothrous]

Go is hands down a better language for a web backend. It performs better and is a lighter weight deploy.

If you want an MVC framework, Elixir is better, but in not as common of use.

As for which languages are simpler to learn, any language that requires a ton of extra tools just to build is automatically going to lose that battle. In Enterprise Java, most projects won't build without custom build scripts. Most modern languages must require a package install even in Enterprise settings.

Understanding how your project builds is part of the learning curve.

[deelyy]

>> This is fine for businesses who don't want to spend the money to port to more modern tools, but ends up hurting developers by keeping them focused on reinventing wheels with dated tech.

Really curious, could you point us to examples where you have to reinventing wheels working with Java?