4 ms·
> If you are ok with it getting as slow as Go, you can get similar safety guarantees as well. FWIW, Rust can make these guarantees without performance penaltie
by vog 11y ago
> If you are ok with it getting as slow as Go, you can get similar safety guarantees as well.
FWIW, Rust can make these guarantees without performance penalties.
- seangrogg 11y agoThere are penalties, they are just relatively marginal.
- kibwen 11y agoSpecifically, Rust does runtime bounds checking when you index into an array. LLVM is theoretically capable of optimizing these checks out if they're unnecessary, but it's far from guaranteed. It would take a dependent type system to perform compile-time bounds checking, and Rust isn't that sophisticated. However, indexing is far, far less prevalent in Rust than it is in C, due to the existence of iterators. I've asked the Servo team on multiple occasions whether the cost of bounds checking shows up in performance profiles, and they never have, likely because they just aren't doing very much indexing to begin with.
- pcwalton 11y ago> There are penalties, they are just relatively marginal. What are the penalties, specifically?
- geodel 11y agoSince Rust does not provide sec-libs in standard distribution nor they are available in larger ecosystem, Rust benefits seems theoretical to me. As with other things in theory C/C++ code could also avoid memory/security issues.
- bluejekyll 11y agoThey do exist in the larger ecosystem, they are just very young. Also, we devs have had "don't build your own crypto" beaten into our heads so often lately that I think people are generally wary of starting new, or using new, projects that haven't already been battle hardened. I've looked at the OpenSSL code, and I have to say that it's not well documented in many cases and easy to make mistakes in it's usage. The rules on when locks are needed vs. not are not always clear, and then the ownership of memory is as confusing as it's always been in C. This is where something like Rust would shine just by cleaning up these interfaces. The Rust OpenSSL bindings, http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ , for example are very sane, and it's difficult to screw up the usage.
- geodel 11y agoDo you mean Rust-openssl bindings will not require patching openssl for Rust apps in case vulnerabilty? In that case Rust surely helps applications written in it.
- dfc 11y agoWhat are "sec-libs"? From the other reply it seems "sec-libs" are the hip mounted pouches of enchanted crypto dust so you can sprinkle it around and get "security".
- pcwalton 11y agoI don't see any other way to read this other than "there's no point in rewriting security code in Rust because security code in Rust hasn't been written yet". That, obviously, doesn't make sense to me.
- geodel 11y agoYou do not see any other way to read because you are looking to argue over innocuous statement which is not even false. Security code in Rust could be great and I will be happy if and when it is available for general use.
- eridius 11y agoI agree with pcwalton, that's how I read it too. The context of this thread is security vulnerabilities in OpenSSL, so it's quite reasonable to read your parent comment exactly as pcwalton did.