3 ms·

The over emphasis on memory safety makes for a very weak pitch. I only spend a tiny fraction of my time on memory related issues. Most bugs are simply not memor

The over emphasis on memory safety makes for a very weak pitch. I only spend a tiny fraction of my time on memory related issues. Most bugs are simply not memory related. If you're writing Firefox or SSL, a memory mistake may be a vulnerability and a serious issue. In games, hpc, hft, etc, a memory mistake is almost always just another bug. Would be great instead to see more examples of how e.g. destructive move in That allows generating better assembly.

steveklabnik 10y ago
> Would be great instead to see more examples of how e.g. destructive move in That allows generating better assembly. One example isn't about the destructive aspect: a move in Rust is always a memcpy. Since there's no move constructors, there's no way to run arbitrary code, so it's always a memcpy. The optimizer can also then elide this copy if it isn't actually needed.
- quicknir 10y ago
  Yes that's what I was referring to, the terminology I used has been used before in C++. Rust s moves are considered destructive in the sense that the old object is no longer functional, which of course is fine because it can't be used.
  - steveklabnik 10y ago
    Oh yeah sorry, I see what you're saying now.
pjmlp 10y ago
In games a memory mistake is yet another way of loosing sales of a game, create bots to win network matches, work around in-game sales of items, ... In HPC a memory mistake is yet another way of producing corrupt results for writing that paper, that after all is wrong. In HFT a memory mistake is yet another way of producing corrupt values, leading to the automated trading bot selling items way lower than they should have been, loosing millions in the process.
- quicknir 10y ago
  It is yet another, exactly. There are many possible mistakes, memory is just one. One that consumes a very small fraction of my time. I'm not a game developer so I can't judge your estimation of bug severity there but it seems highly speculative to say the least. On the other hand your comments vis-a-vis HPC and HFT show that you have very little domain knowledge. Memory corruption is far more likely to crash a program, or to cause results that are wildly wrong. Wildly wrong is not so bad; any scientist worth his salt will question the results and see there are issues. Your comments on HFT are even worse. Exchanges will not accept "selling items way lower", placing orders too high or too low produces rejects. And even if the order is accepted, it simply crosses the book at the best prices on the book. If you want to write about how you really lose millions, read about Knight Capital. Nothing to do with memory. In both HPC and HFT, subtly wrong is a much bigger problem than wildly wrong. And memory is much less likely to produce subtly wrong unless someone is deliberately exploiting it. Again, it's not a matter of this never happening. It's just that it's rare in comparison to all of the other ways in which you can make mistakes, and particularly subtle mistakes. This really seems to be one of the problems with Rust. Most people involved seem to be very firmly in the classical SV-esque tech world, working on browsers or core infrastructural components for the internet, or web servers, or what not. Chrome bugs and heartbleed are the examples du jour. The problem is that this is not the main area of use for C++. The dominant industries for C++ are finance, video games, and HPC, along with some more demanding programs on mobile, or (rarely) on desktop. People like you who lack domain knowledge about the main areas in which C++ are used, stomping their foot and insisting that memory problems are central and that Rust is valuable, does not really achieve anything.

steveklabnik 10y ago

> Would be great instead to see more examples of how e.g. destructive move in That allows generating better assembly. One example isn't about the destructive aspect: a move in Rust is always a memcpy. Since there's no move constructors, there's no way to run arbitrary code, so it's always a memcpy. The optimizer can also then elide this copy if it isn't actually needed.

quicknir 10y ago
Yes that's what I was referring to, the terminology I used has been used before in C++. Rust s moves are considered destructive in the sense that the old object is no longer functional, which of course is fine because it can't be used.
- steveklabnik 10y ago
  Oh yeah sorry, I see what you're saying now.

pjmlp 10y ago

In games a memory mistake is yet another way of loosing sales of a game, create bots to win network matches, work around in-game sales of items, ... In HPC a memory mistake is yet another way of producing corrupt results for writing that paper, that after all is wrong. In HFT a memory mistake is yet another way of producing corrupt values, leading to the automated trading bot selling items way lower than they should have been, loosing millions in the process.

quicknir 10y ago
It is yet another, exactly. There are many possible mistakes, memory is just one. One that consumes a very small fraction of my time. I'm not a game developer so I can't judge your estimation of bug severity there but it seems highly speculative to say the least. On the other hand your comments vis-a-vis HPC and HFT show that you have very little domain knowledge. Memory corruption is far more likely to crash a program, or to cause results that are wildly wrong. Wildly wrong is not so bad; any scientist worth his salt will question the results and see there are issues. Your comments on HFT are even worse. Exchanges will not accept "selling items way lower", placing orders too high or too low produces rejects. And even if the order is accepted, it simply crosses the book at the best prices on the book. If you want to write about how you really lose millions, read about Knight Capital. Nothing to do with memory. In both HPC and HFT, subtly wrong is a much bigger problem than wildly wrong. And memory is much less likely to produce subtly wrong unless someone is deliberately exploiting it. Again, it's not a matter of this never happening. It's just that it's rare in comparison to all of the other ways in which you can make mistakes, and particularly subtle mistakes. This really seems to be one of the problems with Rust. Most people involved seem to be very firmly in the classical SV-esque tech world, working on browsers or core infrastructural components for the internet, or web servers, or what not. Chrome bugs and heartbleed are the examples du jour. The problem is that this is not the main area of use for C++. The dominant industries for C++ are finance, video games, and HPC, along with some more demanding programs on mobile, or (rarely) on desktop. People like you who lack domain knowledge about the main areas in which C++ are used, stomping their foot and insisting that memory problems are central and that Rust is valuable, does not really achieve anything.