Comment by rurban

3 years ago

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.

4 comments

rurban

Reply
thayne  3 years ago

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