Hacker News new | past | comments | ask | show | jobs | submit login

> it crashes because of Rust ownership rules

Ownership rules exist only at compile time and are not the reason it crashes at runtime.




Unless it's using e.g. RefCells to enforce them at runtime


Ownership rules describe an invariant that needs to be upheld both at compile time and run time for Rust code to function.


hmmm…

Ownership rules can be arbitrarily violated by unsafe code which may cause a crash, or undefined behaviour but it does not prevent rust code from running.

Many “violates single ownership rules” (eg. Concurrent mutable references) actually dont break rust, because the undefined behaviour on many platforms happen to be “eh, does whatever c does, which is actually fine”.

It would be more correct to say that they must upheld to guarantee rust code functions correctly.

However, segfaults come from memory corruption, which comes from unsafe code; probably use after drop. It doesnt usually come from violating single ownership rules, and usually it’s from “object was dropped because it was owned and you forgot to keep it alive across a callback boundary” just like c++ code with unique_ptr

…but eh, whatever. The point is it crashes, which means the binding isn’t done correctly, whatever you call it. Lay blame where blame is due; the rust wrapper isn’t safe.


For one definition of "don't break". If you are UB, in my books (including the Rust book), you've broken.

As per your comparison to C, you are mistaken, this would do whatever C does when it has incorrect `restrict` qualifiers.

See how the book phrases it for yourself: https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... The way RefCell works is not described as a similar but different set of rules or invariants, but as enforcing the same rules.

Please do not ignore the compiler's assumptions in your own programs...


You said, and I quote:

> needs to be upheld both at compile time and run time for Rust code to function.

That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.


A program that fails under some circumstances is a buggy program. The fact that it doesn't crash under some circumstances is no redeeming quality at all.

I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?


You said, and I quote:

> needs to be upheld both at compile time and run time for Rust code to function.

That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.

/shrug

If you want to argue a different point with someone, do it with someone else.

I’m simply pointing out that you are categorically wrong in your statement.


I've explained and I've linked references, your last two comments say "not correct". If you don't want to argue don't, if you do please present arguments.

You are not "pointing out" anything, you are stating against evidence.


"crashing" could also mean a panic! caused by the runtime ensuring you have at most one mutable reference to an object.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: