Hacker News Reader

Comment by berkut | Hacker News Reader

> And this is despite the fact that I still don’t know where that particular vector is modified or destroyed — I didn’t explore that far because I didn’t need to! (or want to :P)

I find that a bit worrying - while it might well be an example of what's technically possible in some cases of using Rust to prevent segfault-type crashes, it doesn't mean there aren't now logic errors in the code which would do something just as bad. I guess it depends on how well you know the code and the context in which it's being used.

View on HN

> it doesn't mean there aren't now logic errors in the code which would do something just as bad

Yes, it does. He wants to have immutable access to some data, the Rust borrow checker's rules provide certainty that the data is not deleted or mutated while his code is accessing it.

What could happen that is "just as bad"? Data being referenced cannot be changed.

I think an important thing to make sense of this is that Rust doesn't guarantee that what Manishearth did will work! Just that if it doesn't work, the code will not compile. It could have been the case that this vector was mutated or deleted at some point during the lifetime of his new struct; in that case, his code would not have compiled.

In this case it does.

I was more talking about the overall not caring theme. I'd hope that's only because they know the code so can make those sort of assumptions.

Are you saying Rust can find and prevent at compile time logic errors as well?

You "don't care," I'm sure, about all kinds of things when you're programming - depending on what level you're at. Unless you're drawing up CPU schematics, there is something that you have abstracted away as no longer your concern.

Rust allows you to not care about more things than C/C++ despite compiling to a comparable binary. In particular, Rust makes refactoring and extending a code base much more care-free than many other languages (including high level languages) because of the strong type and memory safety guarantees of its semantics.

EDIT (re: your edit) - No one said anything about preventing arbitrary logic errors, just that what Manishearth did will not introduce logic errors because of Rust's guarantees. This could not be the data that Manishearth wants, but the compiler guarantees that Manishearth cannot change the data or delete the data and that the data is not changed or deleted while he is referencing it. That is what is so great.

What edit? My second comment?

That was my original point regarding logic errors and not caring - yes, it may well be that Rust gives you much more confidence that you don't do invalid/wrong things. But that excludes logic errors (it may well reduce the possibility of logic errors, but it doesn't prevent them), and there's still room in large code bases for things to break even with very good static type checking.

  > I was more talking about the overall not caring theme.

Not having to care about memory management gives me more mental energy for caring about the other parts of my program. The lack of anxiety about memory semantics is one of the most compelling reasons for me to use Rust.

  > Are you saying Rust can find and prevent at compile 
  > time logic errors as well?

In some ways it certainly can. Its type system guarantees at compile time that your code cannot contain data races, making massive concurrency and parallelism much easier to introduce. You can also push the type system to do things like check units for you, such as is done in Servo: https://blog.mozilla.org/research/2014/06/23/static-checking...

Would you find it equally worrying if stack-based languages claimed they improved over x86 because you needn't worry about clobbering values in registers? I guess it depends on how well you know the code and its context. Might still be logic bugs.

And man, functional languages. It's pretty much 100% logic bugs there. I worry most about those sort of programs.

If you only have 100% logic bugs in your code, I'd say the code is in damn good shape. That means all your bugs are "meaningful".

Different programming platforms have different "incidental complexity" causing bugs not related to actual program logic, but merely how it is put together, so to speak. In particular, Rust seems objectively better than C++ in this regard.

What sort of logic errors would be possible? The slice cannot be mutated, and the compiler has verified for me that nobody else is mutating it.

I was just holding on to a reference for an API to consume.

Of course, in more complicated situations you need to worry about logic errors. But in this case I was pretty sure I didn't have anything to worry about.

Still you never have to worry about memory unsafety, which is a huge cognitive load off my mind. Similar to how you don't have to worry about some types of memory unsafety in languages like Java. Or how most programmers don't worry about cache coherence since the processor handles it. Rust just raises the bar. If you know what it can and can't prevent, you can be carefree about many things.

Reply on news.ycombinator.com