> 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe.
That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means?
For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most GC'd languages are memory safe too. However, you can just strap the Boehm GC to C or C++ [2] and that doesn't suddenly, magically, make it memory safe.
> 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it.
Safety means a lot of different things. GC isn't a replacement for safe Rust. Rust offers many kinds of safety, memory safety is just one. And yeah, unsafe is a tool for implementing certain things that cannot be expressed in safe Rust, but it's extremely rare that you would dip into it in production code. It's more for library authors who wrap unsafe APIs in safe ones.
If you're curious what 'safe' rust really means and why the GC doesn't subsume all its features - and the difference between safe and unsafe Rust - I'd recommend [1].
> 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.
Sure in embedded it can be hard, but on a PC you can just use valgrind or the leaks tool. If you're writing embedded code in Rust just don't use Rc or Arc boxes and you can't form a cycle. Remember there's no reference counting in Rust at runtime unless you opt into it with a shared-ownership reference-counting box. All Rust's reference counting happens in the compiler and once the compiler determines your object is no longer referenced, it drops it. If it cannot make that determination statically your build will fail.
Reference counting is generally how resources are managed in GC'd languages since you're explicitly not to rely on the finalizer ever being called. Files, sockets, etc. It's just trading off one kind of problem for another.
[edit] Note that you can also leak memory in a GC'd language by keeping a reference to objects you no longer need - for instance, in some long-lived dictionary or array, or in a static. [3]
Right, but to my knowledge the other “safety” of rust is concurrency, which is easily attainable with something like Elixir.
I’m not saying a GC guarantees all safety, I am saying you can find a GC language that gives all the safety (and technically more) of rust.
My quote of “future unsafety” is that even if your code currently uses only safe rust, their will always be the chance someone adds unsafe rust, increasing the safety issues.
It just seems you can find a GC alternative that will never run into the issues rust can cause, and it will be faster to develope/change (because no borrow checker), and there is no downside.
> I am saying you can find a GC language that gives all the safety (and technically more) of rust.
Giving "all the safety" is theoretically possible, but "technically more" is not. And even if you did have "all the safety", you'd still have the big performance disadvantage with a GC language.
> My quote of “future unsafety” is that even if your code currently uses only safe rust, their will always be the chance someone adds unsafe rust, increasing the safety issues.
No there won't. This is what #![forbid(unsafe_code)] is for.
That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means?
For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most GC'd languages are memory safe too. However, you can just strap the Boehm GC to C or C++ [2] and that doesn't suddenly, magically, make it memory safe.
> 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it.
Safety means a lot of different things. GC isn't a replacement for safe Rust. Rust offers many kinds of safety, memory safety is just one. And yeah, unsafe is a tool for implementing certain things that cannot be expressed in safe Rust, but it's extremely rare that you would dip into it in production code. It's more for library authors who wrap unsafe APIs in safe ones.
If you're curious what 'safe' rust really means and why the GC doesn't subsume all its features - and the difference between safe and unsafe Rust - I'd recommend [1].
> 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.
Sure in embedded it can be hard, but on a PC you can just use valgrind or the leaks tool. If you're writing embedded code in Rust just don't use Rc or Arc boxes and you can't form a cycle. Remember there's no reference counting in Rust at runtime unless you opt into it with a shared-ownership reference-counting box. All Rust's reference counting happens in the compiler and once the compiler determines your object is no longer referenced, it drops it. If it cannot make that determination statically your build will fail.
Reference counting is generally how resources are managed in GC'd languages since you're explicitly not to rely on the finalizer ever being called. Files, sockets, etc. It's just trading off one kind of problem for another.
[edit] Note that you can also leak memory in a GC'd language by keeping a reference to objects you no longer need - for instance, in some long-lived dictionary or array, or in a static. [3]
[1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
[2] https://hboehm.info/gc/
[3] https://www.lucidchart.com/techblog/2017/10/30/the-dangers-o...
reply