On 21/06/14 06:54 PM, Jerry Morrison wrote: > I agree with Vadim that the world will inevitably become > security-conscious -- also safety-conscious. We will live to see it > unless such a bug causes nuclear war or power grid meltdown. > > When the sea change happens, Rust will either be (A)/ the attractive > choice for systems programming/ or (B) /obsolete/. Rust already has the > leading position in memory safety for systems programming, so it's lined > up to go.
No one will use Rust if it's slow. If it uses checked arithmetic, it will be slow. There's nothing subjective about that. > The world desperately needs a C++ replacement for real-time, > safety-critical software before that ever-more-complicated language > causes big disasters. Rust is the only candidate around for that. (Or > maybe D, if its real-time threads can avoid GC pauses.) CACM's recent > /Mars Code/ article > <http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext> shows > the extremes that JPL has to do to program reliable space probes. > Smaller companies writing automobile engine control systems > <http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences> > and such will soon be looking for a more cost effective approach. Trapping on overflow doesn't turn the overflow into a non-bug. It prevents it from being exploited as a security vulnerability, but it would bring down a safety critical system. > Companies like Intel see so much existing C/C++ software getting by > without overflow safety and conclude it doesn't matter. Let's not let > their rear-view mirror thinking keep us stuck. Eventually customers will > demand better security whether there's a speed penalty or not. > > CPU designers could say they've given us so much instruction speed that > we can afford to spend some of it on overflow checking. Fair point. When > the software folks have demonstrated the broad need, Intel can speed it > up, whether by optimizing certain instruction sequences or adding new > instructions. Overflow checking means a branch on every integer arithmetic operation. It means every arithmetic operation is impure (unwinding) so LLVM won't be able to hoist stuff out of loops unless it proves that there's no overflow, which is rare. For example, this prevents it from hoisting a bounds check out of a loop by introducing a second kind of impure failure condition. It also prevents auto-vectorization, which is increasingly important. A language without good auto-vectorization is not going to be an interesting systems language down the road. > The Mill CPU architecture handles overflow nicely and promises much > higher performance, like extending DSP abilities into ordinary software > loops like strncpy(). Whether this one takes off or not is hard to say. > That little company could use a big partner. It has to exist before it can succeed or fail.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
