1. The risk of future unsafety (a GC language will always safer than rust)
2. Faster development that's easier to change on a dime.
3. No risk of memory leaks (which can happen in safe rust)
[citation needed]
> 2. Faster development that's easier to change on a dime.
Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here.
> 3. No risk of memory leaks (which can happen in safe rust)
... at the expense of making collection non-deterministic and significantly more resource intensive. Not to mention that the non-determinism means you generally end up grafting your own resource management scheme on top. I've never seen a company that hasn't at some point had someone crying over GC tuning. Leaks are safe (which is why they're allowed in safe Rust) and generally speaking both a non-issue - and very easy to track down.
Rust has been my daily driver at home since like 2015, and I have to say, I've never once gone "man you know what this thing needs? Shenandoah." I write a bunch of Kotlin too, for what it's worth.
These trade-offs are well known and there are pros and cons to both.
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.
3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.
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
[3] https://www.lucidchart.com/techblog/2017/10/30/the-dangers-o...
