On 03/27/2014 10:04 PM, Tommi Tissari wrote:
By the way, D is memory safe (although it's opt-in) and it has this 
noboundscheck flag. So I don't see what the problem is.

Rust takes a very different stance to safety than to D (e.g. making it safe by default). In the D community my perception was that for any benchmark written in D it has been the suggestion to turn on that noboundscheck flag in order to get extra speed, forming a perception that D is only fast if you turn off this safety feature completely. Not only is Rust's approach more fine grained (although it is possible to do unsafe array access in specific locations in D as well), but it also encourages Rust to be fast /despite/ the safety features.

A big reason for Rusts existence is that it wants to provides C++-level performance while /at the same time/ providing safety. If the only way a Rust user can match C++ speed is by using 'unsafe' everywhere, then Rust will have failed, in my opinion. I didn't look at how the shootout benchmarks are implemented, but if I had any say, I'd forbid them to use any unsafe code (except for FFI where absolutely necessary) to prove the above point.

There are many ways you can avoid bounds checks in safe Rust code. For example, if you restrict yourself to using iterators instead of indexing operators, there will be no bounds checks. You can also code up abstractions (like I did in my matrix library) so that you don't need to pay the bounds check cost as much as well. I really don't think this is a real concern.

-SL
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to