Conversation

Notices

1. Verius (verius@community.highlandarrow.com)'s status on Saturday, 01-Apr-2017 10:22:06 UTC Verius
   The whole trend towards memory safe languages kind of amuses me. We have plenty memory safe languages, they just tend to use a GC so you don't have to think about memory (aside from avoiding reference cycles).
   
   The real reason memory safety is a problem is not because it's not possible with modern programming languages, it's that people want C/C++ levels of performance and that's obtained by letting the compiler and standard library do unsafe things and putting the onus of writing safe code on the application programmer.  
   • Hallå Kitteh repeated this.
   • Verius (verius@community.highlandarrow.com)'s status on Saturday, 01-Apr-2017 10:28:29 UTC Verius

     in reply to
     And before people start about Rust, I'm not convinced it will have the same level of performance as C/C++. Rust is a bargain of restricting what the programmer can do in exchange for correcter code. That inevitably leads to writing code in a less direct way than in C/C++, at least part of the time. The compiler would need to be very good at translating that code to a standard form which doesn't have the indirections in order to gain the same level of performance.
     
     Compilers are good, but I have a hard time believing Rust programmers will always write code that exhibits the properties needed for a compiler to safely rewrite it to the fastest version.
     Hallå Kitteh repeated this.
   • Hallå Kitteh (clacke@social.heldscal.la)'s status on Saturday, 01-Apr-2017 19:18:15 UTC Hallå Kitteh

     in reply to
     @verius I don't know how good the Rust compiler is, but I see no theoretical reason why memory management guarantees evaluated at compiletime would have a performance penalty at runtime. Indirections cost, yes, but I also see no reason why indirections in Rust would pay any higher cost than the equivalent in C++.
   • Verius (verius@community.highlandarrow.com)'s status on Sunday, 02-Apr-2017 08:48:52 UTC Verius

     in reply to

     • Hallå Kitteh
     @clacke It's not a direct link. The borrow checker is necessarily conservative (according to Rusters and this chimes with what I know of type systems), thus it fails programs that are correct but unprovable. It imposes limitations such as that you cannot mutate an object that is borrowed. In some cases code that fails the borrow checker would be correct and more efficient, assuming a straight translation of source to assembly (which we both know compilers don't do).
     
     In order for Rust to be at the same level as C++ the compiler would need to be able to detect workarounds the programmer has made to satisfy the borrow checker and translate that into the same effective code. However optimization possibilities for compilers are limited by all kinds of rules (defined behavior) and for example a function call to a function external to this compilation unit could prevent reordering necessary to optimize.
     Hallå Kitteh repeated this.
   • Hallå Kitteh (clacke@social.heldscal.la)'s status on Sunday, 02-Apr-2017 13:52:57 UTC Hallå Kitteh

     in reply to
     @verius Fair enough. There are correct programs that cannot be expressed in a stricter system, be it typing, memory management, or anything else. I spend most of my time in dynamically (not weakly) typed languages for this reason among others.
     
     Rust allows you to mark code unsafe, and ultimately, if you need to you can drop down to C. But I accept your point that there is code that is straightforward to express in idiomatic C++ that needs extra work in Rust. And this may carry a performance penalty if you stay in idiomatic Rust.