On Tue, Apr 30, 2013 at 7:55 AM, Graydon Hoare <[email protected]> wrote:
> On 13-04-28 03:03 PM, Robert O'Callahan wrote: > > I don't understand the relationship between those features and integer > > overflow checking. There are very strong reasons why those features > > haven't developed, and none of those reasons apply to integer overflow > > checking. > > Sure. It costs performance. That's the reason in all such cases. It's way more complicated than that. Hardware GC and tagged memory words aren't even usable by programs written in mainstream languages, so average users pay a cost for no benefit. For those few people who want Lisp Machines, custom hardware doesn't win because it doesn't reap the economies of scale that mass-market hardware gets. Another problem is that wiring GC and tags into hardware makes it difficult to evolve languages, compilers and runtimes. A performance cost that you can't opt out of is much less tolerable than one you can opt out of. Functional languages with theorem proving don't even cost performance if you go all the way to something like ATS. The problem there is it's just impractically expensive to write the code in the first place. > > > Based on that data and previous experience with this code, I'm certain > > that those occurrences are vastly outweighed by handwritten code that > > tries to detect/avoid integer overflows, and also by arithmetic > > operations that are still vulnerable to overflow bugs in spite of those > > checks. > > For the most part, nobody checks. They weighed the cost of those errors > against the potential performance loss and decided they would prefer to > go fast. > In C the checking is just too ugly without operator overloading. In C++ you can make it look nice, but it's a lot more expensive than it could be if you had compiler support, I expect. Even so, in the browser we write a lot of checking code. Other browsers do too. I'm very sad that people in this space are so quick to trade correctness > for speed. But they do. And they pick languages (in this space) based on > perception of speed. From benchmarks and informal experiments. > I think conflating "people" into one single group is a mistake. Developers who know their code is under constant, malicious attack make decisions differently to other developers. Yes. I'm not sure how else to put this: we're in an unfair fight. We're > trying to ship a language that is safer than C++ but is _being > benchmarked against C++_. > I want Rust to be the ideal language to write a browser in. I think that's more important than catering to people who blindly follow unfair benchmarks, or who don't value robustness against attack. Since the speed is not before us in quantified terms, though, I suggest > deferring this for a bit: we can implement the feature as a check, and > set the flag to default allow, warn, deny, or forbid based on the > results of performance measurements. If it's trivially cheap, by all > means turn it on by default. > Excellent. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
