OK. You folks made good points. How about if I retract "or obsolete" in favor of "or up for big change or not the tool for those purposes"? Maybe abort-on-overflow in suitable cases...
On Sat, Jun 21, 2014 at 5:02 PM, Daniel Micay <danielmi...@gmail.com> wrote: > On 21/06/14 07:55 PM, Benjamin Striegel wrote: > >> No one will use Rust if it's slow. If it uses checked arithmetic, it > >> will be slow. There's nothing subjective about that. > > > > This is the only argument that matters. > > > > If we are slower than C++, Rust will not replace C++ and will have > > failed at its goal of making the world a safer place. The world already > > has a glut of safe and slow languages; if inefficiency were acceptable, > > then C++ would have been replaced long ago. > > > > In addition, bringing up hypothetical CPU architectures with support for > > checked arithmetic is not relevant. Rust is a language designed for > > 2014, not for 2024. > > > > And if in 2024 we are all suddenly gifted with CPUs where checked > > arithmetic is literally free and if this somehow causes Rust to be > > "obsolete" (which seems unlikely in any case), then so be it. Rust is > > not the last systems programming language that will ever be written. > > Not only does the hardware have to provide it, but each OS also has to > expose it in a way that Rust could use to throw an exception, unless the > proposal is to simply abort on overflow. LLVM would also have to gain > support for unwinding from arithmetic operations, as it can't currently > do that. Even with hardware support for the operation itself, giving > every integer operation a side effect would still cripple performance by > wiping out optimizations. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Jerry
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
