Re:Implications of Rewriting a Browser Component in Rust
by mrath on Thursday February 28, 2019 @04:34PM
(#19275443)
about RAII there is quite a bit of support in recent Java versions not quite as good as Rust but there is support.
Data race is one other thing, I do have data race issues but that is very rare. Some of the static analysis tools even catch these anti patterns.
Re:Implications of Rewriting a Browser Component in Rust
by agumonkey on Thursday February 28, 2019 @06:25PM
(#19276430)
Curious about memory usage too
Re:Implications of Rewriting a Browser Component in Rust
by bluejekyll on Friday March 01, 2019 @10:07AM
(#19281250)
I think the best way to look at it is that memory usage becomes predictable and GC pause free. An application of similar scale and implementation between Java and Rust won't necessarily use less memory when in Rust.
Java’s executors improve the world, but I can’t count the number of concurrency bugs that I had in Java that are not possible in safe Rust. This isn’t just my code, btw, but large teams where it’s hard to disseminate good practices when building threadsafe code. If it had been in Rust, those issues wouldn’t have happened.
Other things that I appreciate about Rust over Java is the error handling combined with RAII, doing away with nasty bugs around try’s lacking proper finally statements for closing file handles, etc.
Java has its warts, not everything is just about memory safety.