Re:“Sustainability with Rust” post misleading about Go
by cle on Wednesday February 23, 2022 @02:16PM
(#30445056)
Also good luck if you need to cross-compile. The Go toolchain for that is seamless, Graal’s is non-existent (because it is fundamentally incompatible with the way native image compilation works).
Re:“Sustainability with Rust” post misleading about Go
by pjmlp on Thursday February 24, 2022 @02:10AM
(#30451575)
If you are cross compiling while using Java, you really don't get Java.
Re:“Sustainability with Rust” post misleading about Go
by cle on Thursday February 24, 2022 @09:06AM
(#30454803)
If you are building and distributing executables using Graal native-image, you probably care about cross-compilation.
Re:“Sustainability with Rust” post misleading about Go
by pjmlp on Thursday February 24, 2022 @10:29AM
(#30455782)
Which is an very good example of not understanding what Java is all about.
Re:“Sustainability with Rust” post misleading about Go
by cle on Thursday February 24, 2022 @10:39AM
(#30455911)
Can you please just say what you mean instead of posting vague, shallow dismissals?
Re:“Sustainability with Rust” post misleading about Go
by pjmlp on Thursday February 24, 2022 @11:40AM
(#30456799)
WORA.
Re:“Sustainability with Rust” post misleading about Go
by pjmlp on Thursday February 24, 2022 @02:10AM
(#30451572)
So you are a Java guy and are only aware of GraalVM, while ignoring all the AOT commercial offerings since 2000?
ExcelsiorJET, J/Rockit, Websphere Real Time, PTC or Aicas aren't GraalVM.
Also if you don't want to lose JIT, while having the advantage of AOT compilation, JIT caches are a thing, nowadays available for free on OpenJDK, OpenJ9 and Android (even though it isn't proper Java).
Re:“Sustainability with Rust” post misleading about Go
by brabel on Thursday February 24, 2022 @12:49PM
(#30457827)
I've been working with Java since 2009 only... those things you mention have never been used anywhere I've seen since then (but yes, I heard of them as things of the distant past that no one used).
It's kind of true... but with so many caveats it's almost a lie.
* it compiles so slowly even basic applications can take 10 minutes to compile. What the hell are they doing all that time?!? Go can compile to multiple OSs architectures on the same machine and it takes a couple of seconds even for large code bases!!
* you can't use most of the Java ecosystem as reflection is endemic... good luck manually declaring everywhere reflection will be used.
* the loss of the JIT hurts peak Java performance a lot. Java runs as fast as Go *once the JVM is warmed up*! Native-image peak performance tends to be some way behind.
Not saying GraalVM native-image is useless, it can be used if you have the energy and knowledge to get past the issues... but as someone who konws Go as well as Java, if I am going to the trouble of going native, I'd just use Go without a doubt.