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.
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.
Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?
Right but if you imported one of those crates, then your “safe” rust would have memory safety issues.
So bam, you just introduced memory safety issues into your web API. This is like a C++ dev using C++ and causing memory issues unnecessarily just because they don’t want to use a safe language.
And Elixir has concurrency and memory safety and it’s guaranteed, so no package you import can violate it. Unlike rust, where you can use safe rust and think there’s no violation, but then use a crate and suddenly have memory unsafety and concurrency violations.
These crates worries are wayyy better than normal C++, but they are terrible compared to any actually safe language.
My program might also crash if there's a bug in the kernel's filesystem driver, but that's not my bug. And Elixir has FFI, which definitely lets you do unsafe stuff.
It’s not about crashing, it’s about exposing memory that could lead to security vulnerabilities.
And FFI? As in the Unix extensions? That’s the operating systems calls, not the language. By that logic, python is as dangerous as C++.
It’s crazy how so many people on this thread say rust is the only choice because of memory safety, and are now bending over backwards trying to claim memory safety is no big deal. So much so FFI is now being brought up smh.
Those sorts of security vulnerabilities are possible in Python/Elixir/etc. In both Rust and Python/Elixir/etc., they're only possible when you do certain unusual things. You are claiming that the Rust way does count, but that the other languages' ways don't count, with no justification.
Memory safety does matter. Rust is memory-safe and C++ is not, so your conclusion doesn't follow.
> 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.
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.