Also to point out, you can 100% leak memory in safe rust
"Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.
I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.
GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.
They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention.
There are no GC vs non-GC spaces. The point of Rust is to be able to have memory safety without a garbage collector, that's literally why it was made. Thus, it is expected based on that premise that we be able to use Rust wherever a GC could be used. The fact that unsafe exists does matter, as long as unsafe isn't used. I too can turn a GC language like Java into an unsafe monstrosity, by for example doing raw bytecode tinkering, does that mean that Java is now unsafe? No, unsafe is merely an escape hatch.
Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing.
You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker.
Is there any advantage?
Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.
It matters to whoever is paying for compute. If you get some other benefit, it may be a worthwhile tradeoff, but it always matters.
This kind of attitude is how we get bloated Electron apps that HN (including me) loves to complain about. Speed should be a first class consideration, not something to throw away for later.
> No one is gonna be able to tell Rust vs Go in a web API
Debatable, Discord moved from Go to Rust [0] because they were getting latency and CPU spikes from Go's GC, and I'd assume that's the same with any GC language because, well, the GC has to run sometime. Now you might say that we're not all Discord scale, to which I'd say, like above, there are benefits to Rust that are more than just speed. Cargo alone is nigh unbeatable compared to some other languages. I was trying to get Python to work the other day and was pulling my hair out over venv, virtualenv, pip, conda etc.
And the discord instance was because it was systems/performance critical software they rewrote. They didn’t rewrite there web APIs. Discord mentioned the rewrite is now rust with C++ glueing it together. No way you are using C++ unless you have to.
I’ll agree with you on python venv/pip. Ugh what a mess. I like cargo, but honestly I think you could argue cargo also is an issue. When you bring in 100 crates, you just gotta hope all the unsafe code in them are safe.
A static analyzer found 200 memory unsafety issues in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/
Memory safe GC languages you don’t have to worry about that, and you can get a package manager.
Speed equals money. The same app running at twice the speed uses half the compute resources. You may also gain a lot of simplicity if you don't need to distribute your architecture so early on.
I'm not convinced about this at all. I've had far more issues with memory leaks in JavaScript programs than I have with Rust. The only way you're really likely to leak memory in Rust is creating cycles of Rc and Arc types. But I don't think any of my programs have even contained Rc, and only trivial usages of Arc for global resources, which I absolutely wouldn't want to point to each other. JavaScript will let you create the same problem without making it obvious with type signatures. And while you might be lucky and have the GC sort out your mess, it doesn't always manage to.
It's also worth pointing out that most GC languages can have the same issues as a Rust program (if not more) just by virtue of having FFI. In Python, I can quite happily load a C extension and ignore all the rules. Whereas in Rust, if I want to use a C library, I still need to explicitly declare it as unsafe code.
In practice, I tend to find that I have to think more about how I approach parallel/multi-threaded code in Rust than I do in other languages - not because it's dangerous, but because the compiler doesn't allow code that would break memory safety guarantees. In some ways, that's obviously a bad thing if I'm having to think more, but in my experience, the thoughts often lead to a better design anyway. So in the end, I'm more confident in my Rust code than I am in equivalent code in a GC language.
Many memory safety violations have been discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/
Maybe I wrong on that, but if it can’t guarantee crate safety, then it doesn’t really do anything.
The value of something like "unsafe" is not that your code is magically protected if it isn't there, but rather that it provides a warning sign as to where dangerous code might lie. So if something goes go wrong - or you're just worried something _might_ go wrong - you know roughly where to look. In the same way, if your Python code includes a C extension and you start getting weird segfaults, you can reasonably guess where to start looking.
Except that, because unsafe is so well integrated in the language, you can often significantly reduce the impact of unsafe to only a few lines, and in most cases you won't need to use it at all.