[thayne]

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.

[rurban]

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.

[thayne]

> 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?

[amedvednikov]

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

[seebs]

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.

[zaarn]

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.

[creata]

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.