Comment by rurban
3 years ago
The three securities they guarantee and cannot hold.
Fearless concurrency.
Java also promised memory safety. I still get Null pointer segfaults in Java code.
3 years ago
The three securities they guarantee and cannot hold.
Fearless concurrency.
Java also promised memory safety. I still get Null pointer segfaults in Java code.
> The three securities they guarantee and cannot hold. Could you elaborate?
> null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault
If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two.
"Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
do you your self a favor and search their ticket system for stack overflow. the list gets longer, not smaller.
and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system. alloca() is dangerous for a reason.
unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade??
also read their docs about their unsafeties, and concurrency deficiencies. compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
> do you your self a favor and search their ticket system for stack overflow
First of all, most of those erorors are about stack overflows in the compiler not the compiled program. And secondly, stack overflow isn't a memory safety issue like, say use-after-free, uninitialized variables, data races, etc. If you allow recursive function calls, you can't really prevent stack overflows.
> alloca() is dangerous for a reason
Rust doesn't have an equivalent of alloca.
> unsafe vec, really??
I'm not sure what you are referring to here.
> mutexes in threads, really??
What does this have to do with memory safety? The only language with threads I know of that doesn't have mutexes is Erlang. And rust Mutexes are better than mutexes in most other languages because you can't access the data protected by the mutex at all, unless you have a lock. And the lock is automatically freed when it goes out of scope.
> concurrent blocking IO in this decade??
Again, what does this have to do with memory safety? And for many applications blocking IO is fine. You don't always need the performance of async I/O which adds complexity. And if you do need async i/o, rust has options there too (just not in the standard library).
> also read their docs about their unsafeties, and concurrency deficiencies.
The Rust Programming Language book has one section of one chapter on "unsafety", and that is specifically on using the `unsafe` escape hatch. Yes, there is a separate book about how to write a `unsafe` code that maintains rust's safety garantees. but that is limited to `unsafe` blocks, which in many cases you can just avoid using. As compared to c or c++, where the entire language is full of potential safety problems.
> compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
What "real safe languages" would those be? Can they be used in all the same domains as rust?
3 issues mentioning stack overflow:
https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+sta...
I've never had one in 3 years.
edit: ah, you meant Rust
Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes.
I doubt the rust team will try to "fix" that.
How would anyone go about preventing you from doing that?
Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do.
There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.
But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.
You most likely get NPEs, not segfaults. I have never seen a segfault in Java and the first Java version I used was 1.5.