Hacker News Reader

Comment by 3a2d29 | Hacker News Reader

What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue?

"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.

View on HN

The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions.

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.

Right but to my knowledge (and I could be wrong) that unsafe tag does to prevent it in the crates.

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.

That's true, but again, it's also true in most other languages that your dependencies can do anything they like, including shipping untrusted, compiled C code.

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.

> "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

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.

Right but my main point is this:

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?

I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for you, but they exist.

Fair, but again I think you can get all those things with a GC language.

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.

> Speed in programming never matters except in the systems space.

It matters to whoever is paying for compute. If you get some other benefit, it may be a worthwhile tradeoff, but it always matters.

> Speed in programming never matters except in the systems space.

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.

[0] https://news.ycombinator.com/item?id=26227339

Bloated is the problem, not language speed. I may have misspoke, what I meant was speed in language never matters.

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.

The problem with Cargo is it only builds rust. I agree it's the best language-specific build tool, but I love the monorepo pattern and future proofing insurances that modern language agnostic build systems like Bazel enable / provide.

> 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

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.

If that were true, all enterprise code would still be non-GC

Don't believe the hype: moving from Go to Rust will not make your app (web or other) twice as fast! It might make your developers twice as slow though (as the author of the article noticed)...

> It is easier to leak memory

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.

Reply on news.ycombinator.com