11 ms·

Comparing Rust and Java

268 points by Manishearth 11y ago

merb 11y ago
Great writeup, especially that you are really fair to both and make good statements. > Java has a lot going for it, and I probably will keep using it for some time. Me, too. And I will always keep an eye on rust, especially since I also use Scala. ;) However the only downside of rust, is that crates.io doesn't has so powerful things like Java has in maven. However comparing Libraries of a 20 year old language vs a "some" year old language is somewhat unfair. What I would like would be Java <-> Rust FFI.
- DannoHung 11y ago
  This may make you happy then: https://github.com/sureshg/java-rust-ffi https://github.com/sureshg/java-rust-ffi
  - voltagex_ 11y ago
    Heh, I wonder if I could write a Minecraft mod in Rust with this
    - kitd 11y ago
      I have written a native extension library for Java in Rust. It's really no different from doing it in C. Mind you it was pretty simple. The only slightly bizarre bit is matching the java types to the libc equivalents, and telling rustc that you don't want to enforce snake naming.
- llogiq 11y ago
  Thanks, glad you like it. > crates.io doesn't has so powerful things like Java has in maven Could you elaborate on this? I'm only using maven in a few projects and have only shallow experience with it.
  - merb 11y ago
    Yeah that was badly written. I meant in Maven are way more powerful libraries than in crates.io. Most things in crates.io aren't really "stable" or "useful" (yet). They are in a really early stage, while in Java you have access to thousands production ready / tested libraries. I.E. Pdfbox, Netty, Akka, etc..
    - llogiq 11y ago
      Ah, yes that's true. The java ecosystem had much more time to mature, and it shows.
levemi 11y ago
I love both Java and Rust, this is a great write up! I've been writing C++ recently and when I run into unexpected undefined behavior during run time I very much miss Rust and Java as neither would have happened in either. I'm just not as good at C++ as I am at the other two so that explains it. It does feel freeing in C++ to not have to worry about borrow checking, but I know it will get me into trouble I would have avoided with Rust. I can see the use case for both. Sometimes you just want some code without worrying about doing it perfectly, and sometimes you want to build a nice big application where things are fine tuned and as bug free as possible and in that case I'll probably want to choose Rust. Nothing in my mind though really beats the ecosystem around Java of these three in terms of IDE support, tooling and just simplicity in getting code out fast when you don't need low level access to things. Netty really brings great things to Java, and the many mature web frameworks for JVM languages are probably better than anything available for Rust right now. I'm not sure a sane person would write backend for a web site in C++. :P Anyway I love both Rust and Java 8 and it's great to see them thriving.
- truncate 11y ago
  Speaking of tooling, correct me if I'm wrong but one thing I miss when working on Java (I've not worked much on Java) is intuitive and build/package manager. Java build tools seems to be painful to use outside IDE. Cargo on other hand, I can get started working in minute.
  - chamakits 11y ago
    I have found the opposite to be true in my experience. IDE's have some level of trouble with most popular Java build tools (Maven and Gradle), while they are quite capable command line tools, and they themselves know how to work well with the IDE's (They each have plugins to create the 'meta' files for the most popular IDE's) What issues have you had with which build tool when using it outside the IDE?
    - sk5t 11y ago
      Same here. Maven works great from the CLI, and Eclipse works great as a dumb-ish consumer of the dependencies and Maven reactor stuff in which to write code. But I don't use Eclipse for real build / test / package tasks, nor is the IDE a very nice place in which to configure the project skeleton.
geodel 11y ago
Many great points. It is interesting to note that Rust IDE, when it comes, is most likely to have Java based GUI. > Both Rust and Java keep their generics to compile time. I thought Rust generics are also available at runtime so they are different from Java.
- untothebreach 11y ago
  no, you can have "trait objects" in Rust, which are boxed and use dynamic dispatch instead of static dispatch, but they lose the original type (type erasure -- another similarity with java :)), so they aren't true generics. For example, you could use the `Read` trait as a type: fn some_func(a: Box<Read>) { } but then only the `Read` methods would be available on `a`, you wouldn't be able to access methods from the original type of `a`.
  - geodel 11y ago
    Thanks. I need to spend time and learn Rust. The one thing stopping me is lack of some small work related project which I can try in Rust
  - solidsnack9000 11y ago
    > so they aren't true generics. Why does type erasure mean they aren't true generics?
  - whyever 11y ago
    They don't lose anything compared to monomorphized templates. You can only access methods of the trait in both cases.
- shmerl 11y ago
  > it is interesting to note that Rust IDE, when it comes, is most likely to have Java based GUI. Why is that exactly? I personally don't like Java based GUIs. They are rarely integrated well with the base system. Qt comes closer to it.
  - 11y ago
sremani 11y ago
https://github.com/PistonDevelopers/VisualRust https://github.com/PistonDevelopers/VisualRust Rust development in Visual Studio.
- voltagex_ 11y ago
  I looked at this but never got past Hello World. Have you used it much?
catnaroek 11y ago
> It may be harder to write Rust code than Java code, but it’s a lot harder to write incorrect Rust code than incorrect Java code. This. 10x. And, if Rust's type checker could be integrated with an SMT solver to statically verify array/vector indexing (instead of performing bounds checks at runtime, or using unsafe code), that 10x would become 100x.
- viperscape 11y ago
  That's true for slicing and indexes, but hopefully you can use Iterator then for basic traversal, which does this.
  - catnaroek 11y ago
    Yep, when iterators do the trick, they're preferable to indexing. But some algorithms (e.g., the tortoise and hare algorithm for cycle detection) explicitly require indexing.
    - llogiq 11y ago
      Not necessarily – you can chain iterators and skip elements on the hare.
      - catnaroek 11y ago
        You're right. I was thinking exclusively of the case where you have an array whose elements themselves are indices into the same array.
- llogiq 11y ago
  I'd personally like to find the time to write this – some of the infrastructure (like call graph analysis) is already available. However, I think this is the nuclear option. I have some experience from university where I wrote some Eiffel code, contracts and all that jazz. It often takes some head scratching to figure out the right pre- and postconditions. I'd actually rather see more safe interfaces for the common cases (like iterators and slices) that are ergonomic to use and may actually carry the proof in their types.
DannyBee 11y ago
" so it’s just-in-time compiled" and "As a fully compiled language, Rust isn’t as portable as Java (in theory)" Look, JIT and static compilation are just compilation mechanisms. You can apply them to pretty much any language you want. You can statically compile java[1]. You can JIT Rust. You can compile java with llvm (Azul does it). You can interpret java, rust, C++, etc. You can have hybrids where you start with an optimized statically compiled form and reoptimize it at runtime. Don't ever tie current optimization mechanisms to comparisons of languages. If it's really important to gain performance, someone will do it. For example, JIT of C++ is often not done because it's not worth it compared to automatic profiling and other reoptimization mechanisms. But it can be done :) If you want to compare languages, compare languages. If you want to compare particular implementations of languages, compare particular implementations of languages. Don't say you are doing one and do the other, because it's confusing, and, well, if it matters enough, someone will come along and make you wrong. :) [1] If you are willing to guarantee no class loading. Otherwise, you can statically compile everything that is loaded or run an interpreter or do what you want to new code at runtime
- 2bitencryption 11y ago
  Oh, come on. I think it was a nice article, and all the points you made were just pedantic. Of course we all know that, can't we just enjoy a nice article? Leave it to HN comments to say things like "Don't ever do this thing...".
- imh 11y ago
  Most languages have a single implementation that everyone uses. Unless I'm interested in writing a new implementation (never), then I'm going to be interested in comparisons of languages based on their well supported implementations. Otherwise we get into discussions about sufficiently smart compilers (http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler). I get what you're saying, but there are tons of people who are justified in only caring about implementations.
  - nine_k 11y ago
    Java, JavaScript, Python, C# — all have significant alternative implementations; never mind C++ and C.
jmgrosen 11y ago
A minor point on a great article, but "On the other hand, Java’s enum values are really singleton classes under the hood – so one can define an abstract method in the enum to implement differently in each value, something that would require a match expression (or hash-table, whose construction at compile time some enterprising Rustaceans have built a crate for) in Rust" isn't quite true -- you can implement methods on enums in Rust, too: http://is.gd/M3VJJR http://is.gd/M3VJJR
- dbaupp 11y ago
  I suspect the author was talking about defining methods for individual variants of an enum, something like enum Foo { A, B } impl Foo::A { fn method_on_a(&self) {} }
  - da4c30ff 11y ago
    There is an RFC[1] for making enum variants first-class types. [1]: https://github.com/rust-lang/rfcs/pull/1450 https://github.com/rust-lang/rfcs/pull/1450
  - llogiq 11y ago
    Exactly. I must admit that my wording was not as understandable as it should have been. I'll see if I can rephrase it to better convey the point.
andrewchambers 11y ago
One language I encourage people to try is myrddin http://myrlang.org/ http://myrlang.org/.
lmm 11y ago
If you don't have a hard requirement for manual memory management then there are good rust-like options on the JVM - Scala if you want java-like maturity and tool support, perhaps Ceylon if you want rust-like new-language elegance.

268 points by Manishearth 11y ago

merb 11y ago

Great writeup, especially that you are really fair to both and make good statements. > Java has a lot going for it, and I probably will keep using it for some time. Me, too. And I will always keep an eye on rust, especially since I also use Scala. ;) However the only downside of rust, is that crates.io doesn't has so powerful things like Java has in maven. However comparing Libraries of a 20 year old language vs a "some" year old language is somewhat unfair. What I would like would be Java <-> Rust FFI.

DannoHung 11y ago
This may make you happy then: https://github.com/sureshg/java-rust-ffi https://github.com/sureshg/java-rust-ffi
- voltagex_ 11y ago
  Heh, I wonder if I could write a Minecraft mod in Rust with this
  - kitd 11y ago
    I have written a native extension library for Java in Rust. It's really no different from doing it in C. Mind you it was pretty simple. The only slightly bizarre bit is matching the java types to the libc equivalents, and telling rustc that you don't want to enforce snake naming.
llogiq 11y ago
Thanks, glad you like it. > crates.io doesn't has so powerful things like Java has in maven Could you elaborate on this? I'm only using maven in a few projects and have only shallow experience with it.
- merb 11y ago
  Yeah that was badly written. I meant in Maven are way more powerful libraries than in crates.io. Most things in crates.io aren't really "stable" or "useful" (yet). They are in a really early stage, while in Java you have access to thousands production ready / tested libraries. I.E. Pdfbox, Netty, Akka, etc..
  - llogiq 11y ago
    Ah, yes that's true. The java ecosystem had much more time to mature, and it shows.

levemi 11y ago

I love both Java and Rust, this is a great write up! I've been writing C++ recently and when I run into unexpected undefined behavior during run time I very much miss Rust and Java as neither would have happened in either. I'm just not as good at C++ as I am at the other two so that explains it. It does feel freeing in C++ to not have to worry about borrow checking, but I know it will get me into trouble I would have avoided with Rust. I can see the use case for both. Sometimes you just want some code without worrying about doing it perfectly, and sometimes you want to build a nice big application where things are fine tuned and as bug free as possible and in that case I'll probably want to choose Rust. Nothing in my mind though really beats the ecosystem around Java of these three in terms of IDE support, tooling and just simplicity in getting code out fast when you don't need low level access to things. Netty really brings great things to Java, and the many mature web frameworks for JVM languages are probably better than anything available for Rust right now. I'm not sure a sane person would write backend for a web site in C++. :P Anyway I love both Rust and Java 8 and it's great to see them thriving.

truncate 11y ago
Speaking of tooling, correct me if I'm wrong but one thing I miss when working on Java (I've not worked much on Java) is intuitive and build/package manager. Java build tools seems to be painful to use outside IDE. Cargo on other hand, I can get started working in minute.
- chamakits 11y ago
  I have found the opposite to be true in my experience. IDE's have some level of trouble with most popular Java build tools (Maven and Gradle), while they are quite capable command line tools, and they themselves know how to work well with the IDE's (They each have plugins to create the 'meta' files for the most popular IDE's) What issues have you had with which build tool when using it outside the IDE?
  - sk5t 11y ago
    Same here. Maven works great from the CLI, and Eclipse works great as a dumb-ish consumer of the dependencies and Maven reactor stuff in which to write code. But I don't use Eclipse for real build / test / package tasks, nor is the IDE a very nice place in which to configure the project skeleton.

geodel 11y ago

Many great points. It is interesting to note that Rust IDE, when it comes, is most likely to have Java based GUI. > Both Rust and Java keep their generics to compile time. I thought Rust generics are also available at runtime so they are different from Java.

untothebreach 11y ago
no, you can have "trait objects" in Rust, which are boxed and use dynamic dispatch instead of static dispatch, but they lose the original type (type erasure -- another similarity with java :)), so they aren't true generics. For example, you could use the `Read` trait as a type: fn some_func(a: Box<Read>) { } but then only the `Read` methods would be available on `a`, you wouldn't be able to access methods from the original type of `a`.
- geodel 11y ago
  Thanks. I need to spend time and learn Rust. The one thing stopping me is lack of some small work related project which I can try in Rust
- solidsnack9000 11y ago
  > so they aren't true generics. Why does type erasure mean they aren't true generics?
- whyever 11y ago
  They don't lose anything compared to monomorphized templates. You can only access methods of the trait in both cases.
shmerl 11y ago
> it is interesting to note that Rust IDE, when it comes, is most likely to have Java based GUI. Why is that exactly? I personally don't like Java based GUIs. They are rarely integrated well with the base system. Qt comes closer to it.
- 11y ago

sremani 11y ago

https://github.com/PistonDevelopers/VisualRust https://github.com/PistonDevelopers/VisualRust Rust development in Visual Studio.

voltagex_ 11y ago
I looked at this but never got past Hello World. Have you used it much?

catnaroek 11y ago

> It may be harder to write Rust code than Java code, but it’s a lot harder to write incorrect Rust code than incorrect Java code. This. 10x. And, if Rust's type checker could be integrated with an SMT solver to statically verify array/vector indexing (instead of performing bounds checks at runtime, or using unsafe code), that 10x would become 100x.

viperscape 11y ago
That's true for slicing and indexes, but hopefully you can use Iterator then for basic traversal, which does this.
- catnaroek 11y ago
  Yep, when iterators do the trick, they're preferable to indexing. But some algorithms (e.g., the tortoise and hare algorithm for cycle detection) explicitly require indexing.
  - llogiq 11y ago
    Not necessarily – you can chain iterators and skip elements on the hare.
    - catnaroek 11y ago
      You're right. I was thinking exclusively of the case where you have an array whose elements themselves are indices into the same array.
llogiq 11y ago
I'd personally like to find the time to write this – some of the infrastructure (like call graph analysis) is already available. However, I think this is the nuclear option. I have some experience from university where I wrote some Eiffel code, contracts and all that jazz. It often takes some head scratching to figure out the right pre- and postconditions. I'd actually rather see more safe interfaces for the common cases (like iterators and slices) that are ergonomic to use and may actually carry the proof in their types.

DannyBee 11y ago

" so it’s just-in-time compiled" and "As a fully compiled language, Rust isn’t as portable as Java (in theory)" Look, JIT and static compilation are just compilation mechanisms. You can apply them to pretty much any language you want. You can statically compile java[1]. You can JIT Rust. You can compile java with llvm (Azul does it). You can interpret java, rust, C++, etc. You can have hybrids where you start with an optimized statically compiled form and reoptimize it at runtime. Don't ever tie current optimization mechanisms to comparisons of languages. If it's really important to gain performance, someone will do it. For example, JIT of C++ is often not done because it's not worth it compared to automatic profiling and other reoptimization mechanisms. But it can be done :) If you want to compare languages, compare languages. If you want to compare particular implementations of languages, compare particular implementations of languages. Don't say you are doing one and do the other, because it's confusing, and, well, if it matters enough, someone will come along and make you wrong. :) [1] If you are willing to guarantee no class loading. Otherwise, you can statically compile everything that is loaded or run an interpreter or do what you want to new code at runtime

2bitencryption 11y ago
Oh, come on. I think it was a nice article, and all the points you made were just pedantic. Of course we all know that, can't we just enjoy a nice article? Leave it to HN comments to say things like "Don't ever do this thing...".
imh 11y ago
Most languages have a single implementation that everyone uses. Unless I'm interested in writing a new implementation (never), then I'm going to be interested in comparisons of languages based on their well supported implementations. Otherwise we get into discussions about sufficiently smart compilers (http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler). I get what you're saying, but there are tons of people who are justified in only caring about implementations.
- nine_k 11y ago
  Java, JavaScript, Python, C# — all have significant alternative implementations; never mind C++ and C.

jmgrosen 11y ago

A minor point on a great article, but "On the other hand, Java’s enum values are really singleton classes under the hood – so one can define an abstract method in the enum to implement differently in each value, something that would require a match expression (or hash-table, whose construction at compile time some enterprising Rustaceans have built a crate for) in Rust" isn't quite true -- you can implement methods on enums in Rust, too: http://is.gd/M3VJJR http://is.gd/M3VJJR

dbaupp 11y ago
I suspect the author was talking about defining methods for individual variants of an enum, something like enum Foo { A, B } impl Foo::A { fn method_on_a(&self) {} }
- da4c30ff 11y ago
  There is an RFC[1] for making enum variants first-class types. [1]: https://github.com/rust-lang/rfcs/pull/1450 https://github.com/rust-lang/rfcs/pull/1450
- llogiq 11y ago
  Exactly. I must admit that my wording was not as understandable as it should have been. I'll see if I can rephrase it to better convey the point.

andrewchambers 11y ago

One language I encourage people to try is myrddin http://myrlang.org/ http://myrlang.org/.

lmm 11y ago

If you don't have a hard requirement for manual memory management then there are good rust-like options on the JVM - Scala if you want java-like maturity and tool support, perhaps Ceylon if you want rust-like new-language elegance.