[zzzcpan]

I don't like arguments like that, as they don't have any supporting data. I happen to analyze significant amount of bugs in a large C codebase and things you are talking about don't seem to be as important, as you claim. But well, this is what's wrong with programming languages, nobody cares enough to do some research. That's ok though, we just think about languages differently.

[noelwelsh]

I find it very strange to see an argument that memory safety is not an important property. Here are some arguments for it's importance:

"Memory error exploitations have been around for over 25 years and still rank among the top 3 most dangerous software errors."

http://www.isg.rhul.ac.uk/sullivan/pubs/raid-2012.pdf

Or see work on static analysis of kernels and device drivers like http://research.microsoft.com/pubs/74567/eurosys2006.pdf

I'm very interested to hear what you consider more important sources of errors.

[zzzcpan]

I didn't say that memory safety is not important. I was talking about the need to control memory layout and other bells and whistles.

Anyway, you suggested Rust under false assumptions. Rust doesn't care about reliability and security any more, than most of the modern languages. Even Perl with its taint mode is more secure, than Rust.

[kibwen]

Mozilla's Gecko team is incredibly interested in both uncompromising performance and strong security. Rust is the first language in industry to offer the zero-overhead abstractions of C++ while retaining memory safety (with the exception of perhaps Ada, which has never taken off outside the government sector).

You seem remarkably uninformed as to what Rust's goals are. Allow me to enlighten: reliability is a big, big deal to the Rust developers. Security is a big, big deal to the Rust developers. Speed is a big, big deal to the Rust developers. Memory efficiency is a big, big deal to the Rust developers.

As for your mistaken assertion that such efforts at memory safety are unnecessary in real-world code:

https://groups.google.com/forum/#!msg/mozilla.dev.servo/ufJM...

  >>> * Do we have data showing how many security bugs we could be avoiding in
  >>> Servo in comparison to Gecko? Is the security benefit truly as valuable
  >>> if expected performance benefits don't pan out?
  >>
  >> We've been talking to some members of the security team (Jesse, Brian). In
  >> general the main class of security vulnerabilities that Rust offers a layer
  >> of defense against is memory safety problems in layout, rendering, and
  >> compositing code. Use-after-free is the big one here, but there are others.
  >> I'm not in the sg so I can't run the numbers myself, but I am told this
  >> constitutes a large class of security vulnerabilities.
  >>
  >
  >A quick scan suggests that all 34 sec-critical bugs filed against Web Audio
  >so far are either buffer overflows (array-access-out-of-bounds, basically)
  >or use-after-free. In many cases the underlying bug is something quite
  >different, sometimes integer overflows.
  >
  There are 4 sec-high bugs --- DOS with a null-pointer-deref, and a few bugs
  reading uninitialized memory. The latter would be prevented by Rust, and
  the former would be mitigated to the extent Servo uses the fine-grained
  isolation Rust offers.
  
  There are no sec-low bugs.
  
  Web Audio is an example of a feature which has very little security impact
  of its own. Its security impact is entirely due to bugs where violation of
  language rules can trigger arbitrary behavior. Rust prevents such bugs. A
  lot of Web features are in this category. 

TL;DR: Firefox's Web Audio component, which in theory ought to have practically zero attack surface, contained at least 34 critical and exploitable security vulnerabilities. All of these were a result of the lack of safety afforded by C++. Rust would have made these vulnerabilities impossible.

[zzzcpan]

This is pointless. Of course memory safety is necessary, I never said that it isn't. I was assuming that any sane person would understand that. And guess what? Most of the mainstream languages are safe in that regard. So you cannot claim, that Rust is particularly safe, it isn't. It's safer than C and C++, but that's about it. And that's ok, no need to be offended.

[noelwelsh]

I'm out; this discussion is not productive to me. You have given no evidence to back your claims -- you have no data, to use your phrase, though you are so keen to see mine.

Specifically:

I gave examples of the need to control memory layout and memory allocation.

I gave examples of Rust's features leading to reliability and security -- memory safety and absence of data races.