Comparing Rust and Java

[Grunnt]

I just read a nice article called “Comparing Rust and Java”, well worth a read:
https://llogiq.github.io/2016/02/28/java-rust.html

Although Rust is not mature enough yet for my tastes it offers many things that I enjoy a lot in Java, especially when it comes to holding my hand in avoiding mistakes. Recently I dabbed (again) into C and C++ for a while and did some learning but it’s just too easy to make untraceable mistakes in those languaes for me.

Do any of you feel attracted to Rust for the same reason?

[Roquen]

Rust looks interesting but I’ve never been able to motivate myself to really look at it. I get too many cheerleader like posts (OMG Rust is awesome!) in my twitter feed…that turns me off and the overplayed emphasis on memory safety, which ranks in my list of problems with modern programming languages somewhere after “does it support the PDP-11?”

[princec]

I think the main thing they were trying to bring to the table with Rust is more to do with concurrency than direct memory safety, as such.
The wilfully different lexical syntax is a bit irritating. Too irritating really. But what most turns me off is that it’s still fundamentally a very low-level language that suffers from all the pitfalls of C in that regard, throwing away all the lovely cosy virtual machine stability that I’ve grown to love.

Cas

[princec]

Unrelatedly it irritates me when even “experts” write about the subject but I still see such nonsense as this:

The first obvious difference between Rust and Java is that the latter runs on the JVM, so it’s just-in-time compiled

Cas

[HeroesGraveDev]

@princec

But what most turns me off is that it’s still fundamentally a very low-level language that suffers from all the pitfalls of C in that regard, throwing away all the lovely cosy virtual machine stability that I’ve grown to love.

Could you elaborate more on the “suffers from all the pitfalls of C” part, as Rust is designed to fix some of the most common/irritating problems (memory/type safety and a cross-platform standard library are the two main ones I can think of).

[princec]

Those aren’t really the problems I have with C… most of the problems I have are getting obscure bullshit with makefiles, autoconf, configure, automake, etc. and libraries and types working together. Java and its strictly defined primitive typing system and thoroughly complete, brilliantly documented standard library are just a beacon of shining light. Assembling programs by just plonking a list of jars on a commandline and letting them link automagically is just beautiful. Rust seems to be a traditional sort of systems level language in the same family as C and C++ and I just don’t do systems level programming.

Cas

[delt0r]

Well i don’t really think the build chain in C/C++ is s systems level thing. It like a 1960s thing and everybody has forgot that things can be better. hell lisp is old and showed the world that things could be better!

I mean you run a program to write a script that then writes make files then run another program that uses said make files to finally call the compiler. I mean what universe does any of that make sense? Oh and i haven’t even talked about linking!

Rust, hm? Yea i don’t really understand the whys so perhaps i can’t really comment. I highly doubt claims of “orders of magnitude less memory than java”. Java uses a bit more memory than C/C++ but it is not even 2x for mem hungry applications unless it is written like shit, and well C/C++ suffer the same problem from shit code. Also the concurrent modification that “plagues” java? really? I grew up doing multitreaded applications, in werid langs, but i really have never had a problem in java. All multitreaded code needs some proper planing if you want it to be better than single threaded. But making stuff thread safe is not hard. Again if you don’t program like shit.

It always comes down to the same microbenchmarks that these arguments always end up having. You don’t write good java like C/C++ or Rust. And the other way round. And no matter what shit code will always be shit in any language.

[HeroesGraveDev]

@princec

…most of the problems I have are getting obscure bullshit with makefiles, autoconf, configure, automake, etc. and libraries and types working together…

Cargo (Rust’s official package manager, nearly always installed alongside rustc) is amazing. You add a few lines to a file (library_name="1.2.3"), run cargo build, and your program is compiled along with all its libraries (which can be sourced from the local filesystem, the official repository, or a github repo). I’d argue that it’s far easier to handle dependencies and compilation in Rust than it is in Java.

@delt0r: Rust’s advantage in this case is that it makes it really hard to write bad code. The compiler will scream at you and refuse to build until you write something sensible. That’s not to say you can’t write bad code in Rust, but you really have to go out of your way to do so.

[princec]

Well… I beg to differ on the difficulty of thread safety It’s about the hardest thing there is in programming. So hard there are schools of thought that are along the lines that the whole concept of threads is rubbish and they should be completely abstracted away, which is where Rust is supposed to come in.

However what also bothers me about Rust is that it’s lexically fiddly - ascii symbols overloaded all over the place, abbreviations, etc. The consistency of the Java language is what makes it so accessible. Kotlin suffers in the same way.

Cas

[delt0r]

@HeroesGraveDev

@delt0r: Rust’s advantage in this case is that it makes it really hard to write bad code. The compiler will scream at you and refuse to build until you write something sensible. That’s not to say you can’t write bad code in Rust, but you really have to go out of your way to do so.

I call bullshit. No way a turning complete language ever does that. It is not strong ai. It cannot know that you shouldn’t be allocating all that stuff or not. Or that you don’t need to be doing a n^2 method rather than a n or log n one. Or lazy loading 1000 DB lines with every click of a mouse to create a slugish UI.

Nothing in a language prevents shit code.

Hmm maybe your right Princec. Since it does seem to be a sticking point for so many. But these days where threads simply cannot be too fine grained from a pure architecture/performance point of view, it really shouldn’t be the meal so many make of it.

I remember the good old days of the massive 16 core SG supercomputer we had. It was a top 500 machine at the time and cost millions. I think most phones are now substantially faster.

[HeroesGraveDev]

@delt0r

@HeroesGraveDev

@delt0r: Rust’s advantage in this case is that it makes it really hard to write bad code. The compiler will scream at you and refuse to build until you write something sensible. That’s not to say you can’t write bad code in Rust, but you really have to go out of your way to do so.

I call bullshit.

You obviously haven’t written anything in Rust

The compiler doesn’t need to be smart. It just has to enforce a set of simple rules. If your code doesn’t fit those rules, even if it might be technically correct, it will still get rejected (but in the case of Rust, it’s much more likely the programmer thinks their code is safe when it actually isn’t).

Quote taken from reddit:

Borrow/lifetime errors are usually Rust compiler bugs.
Typically, I will spend 20 minutes detailing the precise conditions of the bug, using language that understates my immense knowledge, while demonstrating sympathetic understanding of the pressures placed on a Rust compiler developer, who is also probably studying for several exams at the moment. The developer reading my bug report may not understand this stuff as well as I do, so I will carefully trace the lifetimes of each variable, where memory is allocated on the stack vs the heap, which struct or function owns a value at any point in time, where borrows begin and where they… oh yeah, actually that variable really doesn’t live long enough.

Rust sort-of splits bugs into two categories: accidental mistakes that can cause everything to catch fire and explode, and poorly designed or broken algorithms. It stops you doing the former by enforcing its rules, but the latter is obviously impossible (as you’ve said).

That said, not having to worry about the former makes it significantly easier to avoid the latter.

[Roquen]

On memory size. It depends. If you write Java in an “OO, best-practices” style, then yeah the memory footprint explodes. If you don’t (and don’t use libraries that do) then it’ll be close to “fill in name of some system programming language”.

[Oskuro]

These types of threads make me think of C/C++ as the Dark Souls of programming: Based on old standards, requires a lot of fiddling to get running properly, and is loved mainly by masochists.

Oh, and lots of people (myself included) claim to love it, yet hardly ever use it. :

[princec]

I find Java to generally use a fair amount more RAM than C++ no matter what I do… stuff like “Hello World” etc. shows you the “absolute” overhead versus systems languages.

Cas

[Cero]

@Oskuro

These types of threads make me think of C/C++ as the Dark Souls of programming: Based on old standards, requires a lot of fiddling to get running properly, and is loved mainly by masochists.

Oh, and lots of people (myself included) claim to love it, yet hardly ever use it. :

Yeah… but there is a difference between punishing (fairly) and being annoying. I like to be punished by Dark Souls any day

[Grunnt]

@princec

Unrelatedly it irritates me when even “experts” write about the subject but I still see such nonsense as this:

The first obvious difference between Rust and Java is that the latter runs on the JVM, so it’s just-in-time compiled

Cas

Could you explain why this is nonsense? I’m far from an expert on the matter but I believe that Oracle’s JVM does some kind of JIT and Rust does not (being compiled AOT). I quote from Oracle’s website:

[quote]Oracle’s Java HotSpot VM is equipped with a highly advanced just-in-time (JIT) compiler. This means that the class files (which are compiled from Java source code) are further compiled at runtime, and they can be turned into very highly optimized machine code. This optimized code runs extremely fast—usually as fast as (and, in certain cases, faster than) compiled C/C++ code.
[/quote]
http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

[princec]

This bit here is complete bollocks:

[quote]the latter runs on the JVM so it’s just-in-time compiled
[/quote]
There’s nothing about “the” JVM that says Java is just-in-time compiled. There are quite a few JVMs around these days. Some of them are JITted, some of them are AOT, some of them are just interpreted. The JVM specification specifies how things should behave, not how they should be implemented, and this seemingly trivial subtlety makes a surprising difference.

Cas

[Grunnt]

Yeah ok, the “so” is perhaps a bit overstated.

[nsigma]

@princec

There’s nothing about “the” JVM that says Java is just-in-time compiled. There are quite a few JVMs around these days. Some of them are JITted, some of them are AOT, some of them are just interpreted. The JVM specification specifies how things should behave, not how they should be implemented, and this seemingly trivial subtlety makes a surprising difference.

Ah, true, but not what I thought you were getting at - Java bytecode is (may be! :persecutioncomplex: ) JIT’ed, Java code itself isn’t (usually! :persecutioncomplex: ).

Dang, you made me want to put caveats everywhere!

[princec]

The devil truly is in the detail.

Cas