3 ms·

> Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production serve

> Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable as the unsafety of C or C++. Just so everyone here is aware, this is by now an outdated complaint against Java. https://vertx.io/blog/eclipse-vert-x-goes-native/ https://vertx.io/blog/eclipse-vert-x-goes-native/ I'm choosing vertx as an example since it competes already with rust and c based applications over at https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks but you ought to be able to compile general programs ahead of time.

ricardobeat 8y ago
Are there any companies using these native images in production?
- victor106 8y ago
  Shared this in this same thread for another comment. The below videos show GraalVM based app loading up Spring framework, and flowable process engine and making a rest call to an external service all in 13 ms!!! Checkout https://youtu.be/9BQiDmvOnZw https://youtu.be/9BQiDmvOnZw https://youtu.be/yLvnkkRys2Y https://youtu.be/yLvnkkRys2Y
- pjmlp 8y ago
  Twitter uses GraalVM in production, you can find several talks from them. Beyond that, enterprises using PTC, Aicas, IBM, ExcelsiorJET JDKs have had the option to deploy AOT native code in production for the last 20 years or so.
cle 8y ago
This is not at all outdated. GraalVM and SubstrateVM are still very new and only support a subset of JVM features. The Vert.x article itself mentions that, as well as this: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md https://github.com/oracle/graal/blob/master/substratevm/LIMI...
- BlackFly 8y ago
  Before I respond, please don't misinterpret me. I think it is perfectly acceptable to choose Rust over Java saying nothing more than, "We felt Rust would be a better fit for the team," or "We were more excited by Rust." However, if somehow you have imposed on you the constraint that you need to compile ahead of time, this is not enough to toss Java out of the running. Vert.x encountered some issues with reflection while Rust simply does not support the sort of dynamic reflection that Java running on the JVM can achieve. SubstrateVM forces you to have compile time reflection, and Rust can also support this to some extent. If Rust is a feasible alternative to Java for you, then you are not going to encounter this limitation if you choose to go with Java. Plus, if you ever decide you do need this power in your application, if you go with Java you can pay the cost of the increased operational expense and install a JVM.

ricardobeat 8y ago

Are there any companies using these native images in production?

victor106 8y ago
Shared this in this same thread for another comment. The below videos show GraalVM based app loading up Spring framework, and flowable process engine and making a rest call to an external service all in 13 ms!!! Checkout https://youtu.be/9BQiDmvOnZw https://youtu.be/9BQiDmvOnZw https://youtu.be/yLvnkkRys2Y https://youtu.be/yLvnkkRys2Y
pjmlp 8y ago
Twitter uses GraalVM in production, you can find several talks from them. Beyond that, enterprises using PTC, Aicas, IBM, ExcelsiorJET JDKs have had the option to deploy AOT native code in production for the last 20 years or so.

cle 8y ago

This is not at all outdated. GraalVM and SubstrateVM are still very new and only support a subset of JVM features. The Vert.x article itself mentions that, as well as this: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md https://github.com/oracle/graal/blob/master/substratevm/LIMI...

BlackFly 8y ago
Before I respond, please don't misinterpret me. I think it is perfectly acceptable to choose Rust over Java saying nothing more than, "We felt Rust would be a better fit for the team," or "We were more excited by Rust." However, if somehow you have imposed on you the constraint that you need to compile ahead of time, this is not enough to toss Java out of the running. Vert.x encountered some issues with reflection while Rust simply does not support the sort of dynamic reflection that Java running on the JVM can achieve. SubstrateVM forces you to have compile time reflection, and Rust can also support this to some extent. If Rust is a feasible alternative to Java for you, then you are not going to encounter this limitation if you choose to go with Java. Plus, if you ever decide you do need this power in your application, if you go with Java you can pay the cost of the increased operational expense and install a JVM.