Hacker News Reader

Comment by acdha | Hacker News Reader

It depends on exactly what features you class in the safety umbrella. Both languages protect against classic C mistakes but Rust has a far more advanced type system and better safety culture. For example, Java has had issues with data races which would have been caught by Rust and things like null safety have historically been an issue.

Both are better than C but I’d expect a good programmer to be more productive in Rust and to avoid more logic errors (which may or may not be security issues), not to mention the many problems caused by widely used open-source libraries written during the bad old days which have extensive dependencies and often enable risky behaviors by default. Culture isn’t a core language feature but it matters.

View on HN

A NullPointerException is not a security vulnerability.

A race condition might, but even then, I'm not sure how likely that is to result in a vulnerability in a garbage collected language.

NPE itself isn’t likely to be exploitable, no, but what I had in mind was more along the lines of code with logic errors handling rare cases where something is null. There’s a lot of tooling designed to catch things like that but the worst code bases tend not to use them because they’d need a lot of cleanup.

No, in Java a data race is a well-defined behavior - the observable values of the field are only those that were actually set by any Java thread, also called no out-of-thin-air values.

This is not generally true of other languages, where it is allowed for the compiler to do whatever it wants in these cases, meaning that once you go down the happy path, nothing can be guaranteed. Also, safe rust preventing data races is again not that big of a thing because if you want to use the same memory region (not read-only) from multiple threads you will have to use unsafe either way.

but with a GC, Java/Go/etc are inherently more safe than rust.

Rust can have double-frees and some of the most serious memory safety errors that those cannot.

Rust’s scoping rules prevent most double free errors. You can get them with certain techniques but it’s also possible, say, use JNI to shoot yourself in the foot, too.

Basically, I’d say that at fond point this gets to be a lot more complicated because you’re talking about which sets of features & cultural practices make you more or less likely to make exploitable errors. Does using a GC buy you enough to balance out the complexity fetish common in the open source Java world? Which is safer probably depends on what type of projects you work on.

It’s just a weird argument to hear someone argue “does GC buy you enough to balance out the complexity…”

Isn’t the whole argument rust vs C++ that rust gives you memory safety even though it’s more complex?

Like if you can tolerate memory issues all of the sudden to avoid complexity then there was no argument against C++ in the first place.

Note that the sentence continued to describe common open source libraries. Rust code may or may not be more complicated than the core Java language but Java as practiced by many people has lots of heavyweight dependencies with various patterns and conventions you have to understand to use them correctly. It's not a linear relationship but the more code you're running the more likely it is that you have something unsafe.

That's also why I mentioned culture: for various reasons, a lot of Java programmers sought ways to make tons of behaviour configurable which also means that there's both plenty of scope for log4j-style mistakes and lots of optional behaviours which might be exploitable even if few people use them. Rust's culture tends not to encourage that kind of thing as much so even though certain types of errors are possible in any language they're not equally common.

Reply on news.ycombinator.com