Hacker News Reader

Comment by myu701 | Hacker News Reader

That's the killer feature why I gave F# instead of my usual C# a chance - it 'does more for me' at compile time vs. run time.

Yes, these are both much higher level than C, but if what I'm reading among other comments is correct, Rust accomplishes an equivalent improvement in compile time checks while still being a systems language.

View on HN

and Rust will prevent data races, which F# won't.

Rust would have tradeoffs here, though. For example, in C# you'd be able to do (non-leaking) graphs and other structures in 100% safe code, while Rust would need unsafe.

You don't need unsafe. This point is brought up a lot, though I understand where the misunderstanding can come from.

Rust is perfectly capable of expressing graphs with zero unsafe code, just currently not in the most optimum implementation.

Is is fine, or suboptimal to the point of being impractical? Genuine question, how bad is this, if quanified?

It is fine and practical.

Adjacency matrices are trivial to implement in Rust. I leverage graphs constantly.

You need to use reference counting or a scoped memory pool. It's totally fine in almost all cases.

Refcounting in Rust is still faster than refcounting in ObjC or Swift (because Rust can avoid using atomics or increasing counts in many cases), but people who use Rust tend to insist on zero overhead, and a truly flexible zero-overhead solution can't be verified statically.

It's slow.

You don't even need "not the most optimum implementation" (assuming you're talking about index-based graphs or something).

You can make non-leaking pointer-based graphs in safe Rust using reference counting (basically what C# does, if you squint) or arenas (if your nodes' lifetimes fit that pattern).

It doesn't need to be unsafe or unoptimal, just use indices into flat memory instead of pointers.

As someone who has personally written Rust code that deadlocked under specific circumstances, I think I can say that Rust does not prevent deadlocks. Not sure about specific types of race conditions, but I don't think it's possible for the compiler to detect all race conditions at compile time.

It is a heck of a lot easier to not make them in Rust than in someting like C and C++. But Rust is not a panacea for asynchronous code.

Rust does prevent:

* Data races

Rust does not prevent:

* Deadlocks

* Race conditions

* Memory leaks

* Logic bugs

That said, it does make some of these things harder to accidentally introduce, but strictly speaking does not prevent them, it's true.

I thought resources were freed when they went out of scope preventing any memory leaks in Rust.

They are, and in a typical program you don't need to worry about leaking memory.

However, it is possible to leak, e.g. if you use a reference-counted type and create a cycle. There's also Box::leak() that does what it says (it's useful for singleton-like things).

That's the common case, but you can still make a reference counting cycle, or have a thread hang while holding onto something, or even just call `mem::forget` on an allocation.

This is different from Rust's guarantees about memory and thread safety, which you can't break without `unsafe`.

You can still introduce them via circular strong reference-counted pointers. The solution of course is to have only one strong reference and many weak ones, but the compiler in principle will let you create a cycle that will never get deallocated.

Reply on news.ycombinator.com