|
|
|
|
|
|
by ActorNightly
1096 days ago
|
|
|
Java programming paradigm is dead in the modern day. You needlessly write way more code that is needed, all without any benefit, relying on third party libraries for main functionalities that may or may not have egregious vulnerabilities like log4shell. The build system also takes needlessly long, because of how many hacks it involves (Groovy being a language designed to fix Java, being used in Gradle build system which runs a whole Java VM just to compile code) Hardware is cheap these days, developer time is more expensive. Use Node or Python. |
|
|
However, Groovy is also a great scripting language with incredibly powerful runtime meta-programming features. In short, that means you're stuck inside often stripped down (Jenkins) or ill-conceived DSLs that you either know by heart, know someone who knows it, or are in for a world of hurt trying to do basically anything.
With Kotlin DSL - even though the stack got even more complex, including embedded scripting host inside embedded JVM and all that - you get auto-completion in the IDE and "go to definition". That resolves half the problem with Groovy, which is discoverability. The other half - the byzantine object model and PERL-like "there's more than 1 way to do it" - won't go away just by changing the scripting language. Still, it's better.
There's also the thing about versions and compatibility between Gradle versions, Kotlin versions, and plugins versions. Finding the right combination takes so much effort that seemingly nobody ever bother to update the build tools in projects. Unless there's a "build engineer", which sounds kind of dystopic, but after working with Gradle for half a year I have to admit that managing the builds properly is indeed a full-time job.
> Hardware is cheap these days, developer time is more expensive. Use Node or Python.
It's not that simple. Sometimes, latency matters. Sometimes you really need something to happen in 20ms. But then you won't be using Java, or what pjmpl would say, you wouldn't use the stock JVM, but something that provides AOT compilation.
There are so many dimensions you need to consider when choosing an implementation language for something, and Java can be an optimal choice in many situations. As unfortunate as I think it is, the problem is not technical, but cultural. People who started programming in Java will have this rigid, rule-based concept of what you can and cannot do. Their minds are semi-permanently stuck in Java-like mold. Since Java is so all-encompassing, they are never confronted on their beliefs. Echo chamber. Cargo culting. Prevalent in all monocultures. The problem is when they switch to another language and infect it with beliefs that stopped being well founded due to the changed circumstances. They do their best to fit the new language into Java-esque shape, no matter how pointless it seems.
Kotlin is the biggest victim of this. There's so clearly visible divide between "make Java great again" crowd vs. "it's actually a nice language, why not use it for what it is?" crowd. They produce drastically different libraries, have very different goals, and do very different projects. Different values, methods, and outcomes. In itself, it's maybe OK, but... try being stuck in the wrong camp... and stay sane.