3 ms·

> You approach problems differently when you expect memory bugs to appear compared to thinking the chance is 0%. The chance is never 0%, and nobody should be t

> You approach problems differently when you expect memory bugs to appear compared to thinking the chance is 0%. The chance is never 0%, and nobody should be thinking that way. Memory safety bugs routinely arise in JITs (e.g. JavaScript engine CVEs). In fact, memory safety issues routinely arise in CPUs (e.g. rowhammer). In reality, terms like "memory safety" are rarely ever exact, but they're still useful descriptions. Practically, people should be thinking about frequencies, not in black and white.

cogman10 5y ago
Yup. I've created a memory leak in java. Not a "I forgot to free memory in a map" memory leak but a honest to goodness "This JVM is allocating heap space and losing track of that allocation". Something that required me to install a special malloc in the VM to track down the leak. This was using standard libraries (You can do it too! Go play with the Deflater and Inflater API and you'll find it makes calls off to Zlib. If not properly handled you end up leaking heap allocations). That was the first and only time I've ran into that issue, but I ran into that issue. The guardrails rust gives you are essentially the same that the JVM gives you. That is, use only safe code and (barring a compiler bug) you are safe. However, bad things COULD (not will) happen if you use unsafe blocks. Just like bad things can happen in JNI blocks or places where Java makes use of C libraries for functionality. And that is what makes rust fantastic. It's got memory safety up there with JVM safety without a garbage collector. It even has nifty keywords (unsafe) to keep developers on their toes when they need it. Just like Java's JNI or Pythons C extensions. In fact, I'd argue that rust unsafe ends up being more safe than either JNI or C extensions primarily because it is something that can be audited very quickly across all rust code bases. Have a memory issue? It's in the unsafe block.

cogman10 5y ago

Yup. I've created a memory leak in java. Not a "I forgot to free memory in a map" memory leak but a honest to goodness "This JVM is allocating heap space and losing track of that allocation". Something that required me to install a special malloc in the VM to track down the leak. This was using standard libraries (You can do it too! Go play with the Deflater and Inflater API and you'll find it makes calls off to Zlib. If not properly handled you end up leaking heap allocations). That was the first and only time I've ran into that issue, but I ran into that issue. The guardrails rust gives you are essentially the same that the JVM gives you. That is, use only safe code and (barring a compiler bug) you are safe. However, bad things COULD (not will) happen if you use unsafe blocks. Just like bad things can happen in JNI blocks or places where Java makes use of C libraries for functionality. And that is what makes rust fantastic. It's got memory safety up there with JVM safety without a garbage collector. It even has nifty keywords (unsafe) to keep developers on their toes when they need it. Just like Java's JNI or Pythons C extensions. In fact, I'd argue that rust unsafe ends up being more safe than either JNI or C extensions primarily because it is something that can be audited very quickly across all rust code bases. Have a memory issue? It's in the unsafe block.