That's very harsh. If it were a bunch of cobbled together perl and bash scripts I could understand poopooing the software stack, but java for enterprise accounting software is a super common stack and arguably one of the most suitable solution for this type of software.
Or Kotlin. People usually complain about JVM but lots of enterprise software runs on it. Spring boot ecosystem provides lots ready to use libraries. Kotlin can be much easier to use compared to Java.
Yes Go can be better language now, but still lacks lots of library and API support. And Rust, I'd rather code in jvm language fast and ship it fast than building up whole infrastructure that takes way more time to implement.
In my main gig we run on kotlin (fintech/accounting saas) and I absolutely despise it, the overhead is massive. But I wouldn't want to write it in golang, we really need proper OOP. It's also so unbearably slow, it's actually impressive. But it is what it is ¯\_(ツ)_/¯
Also, to be fair, a big part of the slowness is also the tooling, Spring Boot, Hibernate etc. You can mitigate that by using micronaut or exposed/krush, but we only have a microservice running on that. The main business logic is the classic java web stack. Tests, running the app, building takes forever.
It is just my preference. But your right, java is very "enterprise" hence my trepidation. I think there are much better enterprise worthy languages now, like Go. Which are far easier to develop and maintain.
I'm not the OP, but generally JVM applications are very resource hungry under small loads, although I will concede this matters less as load increases, and the extreme OOP style of programming that Java encourages, in my opinion, leads to a lot of faults that require more operational babysitting than I'm ok with.
I don't have any empirical evidence, just experience. As such I'm very biased against it.
Java was great at the time it was created. But now, I think there are several better languages that are more suited for today. Like Go as an example. Easy to develop and easy to maintain. You get very good performance for little effort. It is just my personal preference, but I don't care to maintain Java or JVM anymore. FWIW, I was at the very first every Java One conference. Have used it for many years.
It might make sense to revisit your stance given the most recent JEPs that have been introduced. Java 19 introduced virtual threads and structured concurrency, which will arguably make Java + the JVM a great alternative to Go, etc. Especially since it's very backward compatible.
W/ Graal as well, the AOT compilation comes 90% of JIT performance.
I really think the JVM is an exciting eco-system that has a very bright future if it keeps going the way it is. Brian Goetz' "Paving the on-ramp" discusses how to reduce the boilerplate even further. So these things are definitely a priority for the Java/JVM team[0].
It's GPL with the 'classpath exception' so that you're even exempt from the GPL the you link. Seems pretty good licensing? Do you prefer even more permissive than that?
This is no longer a real reason. It's licensed as GPL with a "classpath exception." That's pretty permissive and this article[0] does a pretty good job of explaining some questions you may have.
