Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (761)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (845)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Comparing Rust and Java  (Read 9316 times)
0 Members and 1 Guest are viewing this topic.
Offline Grunnt

JGO Kernel


Medals: 143
Projects: 8
Exp: 5 years


Complex != complicated


« Posted 2016-02-29 06:21:40 »

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?

Offline Roquen

JGO Kernel


Medals: 517



« Reply #1 - Posted 2016-02-29 08:58:41 »

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?"
Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2016-02-29 10:42:43 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2016-02-29 10:54:45 »

Unrelatedly it irritates me when even "experts" write about the subject but I still see such nonsense as this:
Quote
The first obvious difference between Rust and Java is that the latter runs on the JVM, so it’s just-in-time compiled

Cas Smiley

Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #4 - Posted 2016-02-29 22:14:48 »

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).

Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2016-02-29 22:51:01 »

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 Smiley

Offline delt0r

JGO Wizard


Medals: 143
Exp: 18 years


Computers can do that?


« Reply #6 - Posted 2016-02-29 23:08:00 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #7 - Posted 2016-02-29 23:34:27 »

...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.

Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2016-02-29 23:37:06 »

Well... I beg to differ on the difficulty of thread safety Smiley 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 Smiley

Offline delt0r

JGO Wizard


Medals: 143
Exp: 18 years


Computers can do that?


« Reply #9 - Posted 2016-03-01 00:52:50 »

@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.

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #10 - Posted 2016-03-01 01:30:42 »

@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 Wink

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:
Quote
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.

Offline Roquen

JGO Kernel


Medals: 517



« Reply #11 - Posted 2016-03-01 08:44:27 »

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".
Offline Oskuro

JGO Ninja


Medals: 77
Exp: 10 years


Coding in Style


« Reply #12 - Posted 2016-03-01 09:12:44 »

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.  Roll Eyes

Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2016-03-01 09:57:42 »

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 Smiley

Offline Cero
« Reply #14 - Posted 2016-03-01 14:39:44 »

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.  Roll Eyes
Yeah.... but there is a difference between punishing (fairly) and being annoying. I like to be punished by Dark Souls any day Cheesy

Offline Grunnt

JGO Kernel


Medals: 143
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #15 - Posted 2016-03-01 14:51:27 »

Unrelatedly it irritates me when even "experts" write about the subject but I still see such nonsense as this:
Quote
The first obvious difference between Rust and Java is that the latter runs on the JVM, so it’s just-in-time compiled

Cas Smiley

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.
http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2016-03-01 14:57:52 »

This bit here is complete bollocks:
Quote
the latter runs on the JVM so it’s just-in-time compiled
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 Smiley

Offline Grunnt

JGO Kernel


Medals: 143
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #17 - Posted 2016-03-01 15:08:25 »

Yeah ok, the "so" is perhaps a bit overstated.

Online nsigma
« Reply #18 - Posted 2016-03-01 19:06:38 »

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!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1038
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2016-03-01 19:36:48 »

The devil truly is in the detail.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (351 views)
2018-06-10 19:43:48

EgonOlsen (344 views)
2018-06-10 19:43:44

EgonOlsen (292 views)
2018-06-10 19:43:20

DesertCoockie (515 views)
2018-05-13 18:23:11

nelsongames (843 views)
2018-04-24 18:15:36

nelsongames (829 views)
2018-04-24 18:14:32

ivj94 (1251 views)
2018-03-24 14:47:39

ivj94 (395 views)
2018-03-24 14:46:31

ivj94 (1058 views)
2018-03-24 14:43:53

Solater (413 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!