Hacker News Reader

Comment by mustache_kimono | Hacker News Reader

> I don't buy that at all though. Logic bugs are far more common, you will still have to carefully review each line and section.

I think the parent's point is that it's less likely a bug will be "lurking". You may disagree with that point too, but I tend to agree that it's more likely a memory safety issue is "lurking" than a logic bug is.

View on HN

Maybe it can be reworded to say that the energy you spent on looking for memory issues is saved and can allow more focus on logical errors.

I find doing a code review a demanding task that leaves me drained by the end of it. Despite being drained, I still I don't feel confident I've been thorough enough.

Agree. And say as much in my response to a sister comment.

It doesn't change the point I'm making that just because something is written in Rust means it will require less strictness of code review. There might be a class of bugs that are more difficult to hit in rust but that's just one of many bug types. You can still write terribly buggy code in rust. Assuming less strict review is necessary would be overall worse for the project and likely let _more_ bugs in.

> Assuming less strict review is necessary would be overall worse for the project.

Maybe? It might make it easier for those less experienced with C/C++ memory safety issues to review? Instead of thinking of it as being less strict, I might think of it as -- freeing the reviewer up to focus on other issues.

Let's make it a bit more concrete with an actual example of submitted code.

Here's a recent patch I wrote "Improve E0308: suggest user meant to use byte literal, w/ tests and fix" which adds a suggestion for Rust's diagnostic when you write for example '*' the literal char, Unicode U+002A but it needed a single byte and that's not what a char is. My code suggests adding the prefix b, so writing b'*' here, meaning the ASCII code for that symbol 0x2A which is a single byte ::

https://github.com/tialaramex/rust/commit/130d02b62e65c5f2a4...

I wrote that code but I don't understand the internals of how self.tcx.sess().source_map().span_to_snippet(span) works. Not my problem, we're in the diagnostics code so even if this is perhaps slightly slower than optimal it doesn't matter because a human will need to read this output and act on it - E0308 is a type mismatch, the program does not compile as written.

Does my reviewer know? Maybe, I didn't ask them, but they don't really need to, it's clearly fine here to call this stuff, there won't be a nasty surprise "Oh, make sure you restore the FQ5 when setting Z due to calling sess() in this code" because that's not how Rust works whereas in a language like C++ of course such traps may exist.

Now there is some risk I made a logic mistake, but, I wrote tests for this of course, unlike with subtle memory safety bugs, logic bugs are often caught by proper testing. My tests here are somewhat superficial, I check 'X' and '#' which should both cause the suggestion, and I check '€' which should not, but I think they cover the cases the compiler will really see here.

It means that you can focus your attention on catching logic bugs, instead of dividing attention between memory safety and logic bugs.

That is surely a win, no?

I think it will make the code reviews potentially more interesting, as it removes a class of things that needed to be dealt with before.

Reply on news.ycombinator.com