
Comparing Rust and Java (2016) - dcminter
https://llogiq.github.io/2016/02/28/java-rust.html
======
dcminter
I realise this article's getting a bit long in the tooth, but I thought it was
well written and it was an interesting read for me as a Java developer who
barely dabbles in Rust.

Does anyone have pointers to similar articles of a more recent vintage, or
observations on the state of play in 2019.

~~~
jillesvangurp
The article makes a few valid points about Java. It's worth pointing out that
there are some changes happening to Java, the JVM, and the wider ecosystem of
languages running on it.

One big disadvantage of Java has been the lack of value types and the reliance
on heap memory vs. stack memory, which is what languages like Rust would use.
This is changing and they are in the process of supporting value types in
Java. Currently it's unclear with which release this will land but work here
is progressing. This will improve performance for a number of use-cases where
the advantage is currently for languages like rust. Of course Rust has many
other advantages that give it an edge but this is a fairly big deal and it's
likely to narrow the gap a little.

Another big change is the introduction of the graal vm and ahead of time
compilation that supports. This does not work for all programs as some things
like e.g. using reflection prevent using this. However, frameworks are
evolving that enable using this. This means faster startup times and lower
memory foot prints; which is useful for e.g. server-less type environments. Of
course the flip-side is that you miss out on run-time optimizations that
hotspot would do as well as some of the more advanced garbage collectors.

Finally, Kotlin as a language is addressing a lot of the concerns people have
about the Java language. It's similar to Swift and like Swift and Rust,
there's also a llvm native compiler for it. A lot of the cross platform Kotlin
libraries are written such that they work in both native and jvm environment.
Additionally those same properties also make them usable with the Graal vm.
So, it's no longer true that Java (and Kotlin) code is limited to the JVM.

IMHO graal and kotlin native are going to be interesting. Kotlin native is
currently in beta and the graal vm is still relatively young. As this stuff
matures, there is inevitably going to be a some movement of people to those
runtime environments. Also popular frameworks like Spring (which is
increasingly Kotlin centric) are also focusing on facilitating using the Graal
vm.

Finally, they've been working on improving interacting with native code. This
currently requires writing a lot of stub code and they are working on
automatically generating that. This will facilitate easier interoperability
with Rust and other native languages on the JVM and on Graal and is probably
going to be a big deal for e.g. Jruby and other scripting languages on the
jvm.

~~~
pjmlp
As addendum, since around 2000 many commercial implementations of Java did
support AOT compilation, or some form of JIT caching, Hotspot was the
exception here.

In fact, the OpenJDK CDS feature was originally part of BEA J/Rockit JVM,
later acquired by Oracle and made a commercial feature in Oracle JDK, until it
finally landed on OpenJDK.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=11192952](https://news.ycombinator.com/item?id=11192952)

