Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust – What made it “click” for me (Ownership and memory internals)

deavid.wordpress.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Rust – What made it “click” for me (Ownership and memory internals)

#71

Post by kazinator »

felurx wrote: post #68
SAI_Peregrinus wrote: post #67

Earlier quoted context omitted.

The latter device is very easy to make with a power cord and some wire cutters & strippers though.

And you can use `unsafe` in Rust, code up all sorts of memory-unsafe stuff and have it blow up in your face. In both cases, it should be clear to you that you are behaving in a possibly dangerous manner, that you should know what you're doing and that you are responsible for not endangering others with whatever you're doing.

In a sane language, you can hook up objects in a graph structure with cycles and pass the whole thing (or any portion thereof) wherever you want without having to abandon safety.

Making safe things unsafe: rusterfuck.

Re: Rust – What made it “click” for me (Ownership and memory internals)

#72

Post by the_arcadian »

> Ideally, you don’t want to make a self-referential struct in Rust. Instead you should leverage other types to accomplish the same thing; for example Rc can be used for things like linked-lists or trees. Also, have a look for libraries that might do this work for you, as these are very easy to do wrong.

LOL, sure borrow-checked reference counted pointers that can't equal null to mark the beginning or end of a chain are exactly what I am looking for when I want to build a linked list or tree. Why are you like this, Rust?

Re: Rust – What made it “click” for me (Ownership and memory internals)

#73

Post by 112233 »

kazinator wrote: post #66
felurx wrote: post #61

Earlier quoted context omitted.

I think there might be a misunderstanding here: The analogy works precisely in that you can't plug in anything dangerous because the electrical codes make it so that dangerous things don't exist , and because circuit breakers protect you from malfunctioning stuff. You can't plug a device that pulls 10kW into a plug and have it work, because the circuit breaker stops you from overloading your circuits. You can't plug…

Are you saying that memory management under which I can confidently any object anywhere in the program without any puerile borrowing protocols isn't safe ? Or, else, what is your point?

Yes it is not safe. Just because you do not access undefined memory in an untyped GC language like javascript or python does not mean you can enforce that program invariants are maintained. You still get resource leaks, races, corruption etc. just without a crash (which makes it arguably worse because the defect is not immedeately apparent) Encoding program invariants cannot have "correct" solution, because you must balance expressivenes with compile time decidability.

Re: Rust – What made it “click” for me (Ownership and memory internals)

#74

Post by kaba0 »

sshine wrote: post #5
DarkNova6 wrote: post #2

> As said earlier, C++ developers have an advantage on understanding Rust because they have a mental model of what the memory looks like, pointers and so on The immeasurable success of Rust certainly lies in its clear communication and forcing developers to learn about the basics of hardware. I can't help but to feel validated in thinking that every developer worth its salt should know about these basics anyway. But…

I know the basics. But manually managing memory lifetimes you only learn from a lot of exposure to C/asm. In my first 3 months of Rust, I spent an equal amount of time with the type-checker and the borrow-checker. A year in and I don’t really have a separate phase of resolving borrow-check errors before I can compile. People with more C exposure tend to think that way already.

> But manually managing memory lifetimes you only learn from a lot of exposure to C/asm

Why C? It is not any lower than Rust, one might even argue that Rust is lower-level than C due to it having control over SIMD and the like without non-portable compiler extensions.

Re: Rust – What made it “click” for me (Ownership and memory internals)

#75

Post by kaba0 »

ReflectedImage wrote: post #70
imron wrote: post #8

Earlier quoted context omitted.

If you’re a safe c++ programmer who never writes code that has memory errors, you need to be tracking ownership and lifetimes. Once you get your head around the borrow checker, Rust takes a lot of that cognitive load off you, by tracking things for you at compile time and dinging you on it if you get something wrong.

Rust imposes a lot more constraints than just what is needed to make it safe. It imposes constraints to make it provably safe according to Rust's internal theorem prover. I'm not convinced Rust & C++ have as much in common as you think. Rust is really familar to OCaml or Haskell users.

Rust is literally C++’s RAII made into a compiler-checked concept.

Re: Rust – What made it “click” for me (Ownership and memory internals)

#76

Post by kaba0 »

112233 wrote: post #73
kazinator wrote: post #66

Earlier quoted context omitted.

Are you saying that memory management under which I can confidently any object anywhere in the program without any puerile borrowing protocols isn't safe ? Or, else, what is your point?

Yes it is not safe. Just because you do not access undefined memory in an untyped GC language like javascript or python does not mean you can enforce that program invariants are maintained. You still get resource leaks, races, corruption etc. just without a crash (which makes it arguably worse because the defect is not immedeately apparent) Encoding program invariants cannot have "correct" solution, because you must…

Both JS and python are safe from races and corruption, unless you very explicitly go out of your way. JS has no parallelism, and python has the GIL.

Leaks are not a security concern (besides DOS attacks).

Post reply on HN