Comment by jmartrican | Hacker News Reader

Comment by jmartrican | Hacker News Reader

Parent Full thread

> it requires additional software to run

Many languages require additional software to run.

> Java is an impressive tech, but I still fail to understand why it is so popular.

I used to write C++ as my goto general purpose language. After using Java once I was hooked. It was much easier to do stuff and manage my dependencies.

I think Java has 3 things going for it.

1) The ecosystem is huge. To dethrone Java for backend do not just compare another language to Java, you have to compare its ecosystem. Java has a huge ecosystem especially with Spring Boot tieing many of the most popular parts of that ecosystem together.

2) Speed. Some languages are easy to use. Some are very fast. It seems to me that if one were to quantify ease and speed and plot a min-max graph, Java would be up at the top... best performance with ease of use.

3) Here I am going to throw a hodgepodge of things that can be argued but when taken together amounts to a big deal. Reliability (its used in so many places that by the time you go to write your code rest-assured you are not stumbling onto a new bug), write once, swap JVM's, advanced garbage collection (G1 and beyond, GC is something that is constantly being tweaked and improved), evolution (Java evolves with the times, it biggest gripes became the next thing being addressed), Maven/Gradle (advanced dependency management and build orchestration... these tools are very powerful), Junit/mockito and other testing tools (very powerful testing suites).

+1 for Spring boot and the Spring ecosystem in general. I said it here a few weeks back, Pivotal(the company behind Spring) continue to keep that ecosystem innovative, modern, stable and performant and open sourced. That’s amazing...

We had a few rails developers work port some of their apps to Spring Boot, they struggled initially but after getting over that hump their feedback was it’s light years ahead of rails in terms of ease of use and performance. Easy of use = Groovy & Kotlin both of which compile to the JVM

The real game changer is when Spring runs on GraalVM. Once that happens it would be really really hard to beat java on the backend

I agree Spring has for most intents and purposes won the framework wars (which however also speaks to the relative stagnation in that space). What do you specifically expect from Spring running on GraalVM?

I'm not sure about the availability and maturity of the new-fangled Graal/Truffle/SubstrateVM stuff. I've being eying migration strategies away from the JVM for quite some time now, and towards JavaScript specifically due to its momentum and portability. Both Oracle and RedHat (or their employees as personal projects) had been running efforts for a node.js-compatible runtime system on the JVM several years ago. Now GraalVM provides a polyglot runtime for JavaScript and Ruby, but my understanding is it'll be commercial-only once it's released. So in a way, Oracle is preparing a Java exit strategy themselves :)

> What do you specifically expect from Spring running on GraalVM?

Mostly performance gains you get from AOT. I think GraalVM ( or similar technologies) is going to be a game changer for all langs that compile to intermediary byte code.

Unfortunately, GraalVM does not compile Spring as Spring uses reflection a lot and GraalVM does not fully support reflection. https://github.com/oracle/graal/issues/348

Performance gains of GraalVM's AOT are drastically reduced startup time (1 ms for my Java/Kotlin command-line applications), elimination of JIT warmup time, and reduced memory footprint. For peak performance of a language as dynamic as Java, a JIT is hard to beat. Profile-guided optimizations will narrow the gap but are only available in GraalVM Enterprise Edition. Native executables also have a less sophisticated GC than HotSpot.

Thank you for sharing your knowledge. Its insights like this that make hn so awesome.

> Now GraalVM provides a polyglot runtime for JavaScript and Ruby, but my understanding is it'll be commercial-only once it's released. So in a way, Oracle is preparing a Java exit strategy themselves :)

Your understanding is wrong.

GraalVM comes in two editions: Community Edition (CE) and Enterprise Edition (EE) (https://www.graalvm.org/downloads/).

Community Edition is open-source (https://github.com/oracle/graal) and has a relatively permissive license (GPL v2 + Classpath exception, all source files have the Classpath exception). The Classpath exception was added recently and will make a world of a difference.

Enterprise Edition provides additional optimizations and commercial support. Nevertheless, CE will take you a long way. Twitter says they have achieved a 12% speedup in the real world by running their Scala services with CE's Graal JIT.

All language implementations have been open-sourced by now (except for some EE optimizations). Most of them (including Graal.js and TruffleRuby) are licensed under Universal Permissive License or Eclipse Public License.

My favorite use of GraalVM is creating native executables with Substrate VM. Works great and brings startup time of my Java/Kotlin command-line applications down to 1 ms.

Tool support should be mentioned too. Eclipse or IntelliJ come to mind, the on-the-fly compilation and error checking, code navigation and debugging support are huge power multipliers.

Your inclusion of Gradle in point (3) is in tension with point (2) in that Gradle runs at snail's pace. I do wonder whether running Gradle atop Graal will help with that problem, though I guess to get the benefits Gradle would have to be both built with and running build scripts written in statically-typed languages only, i.e. Kotlin instead of Groovy. It might even stop the developer exodus from Gradle to Bazel.

Reply on news.ycombinator.com