5 ms·
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 l
by myu701 7y ago
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.
- gameswithgo 7y agoand Rust will prevent data races, which F# won't.
- brighteyes 7y agoRust 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.
- PudgePacket 7y agoYou 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.
- ClumsyPilot 7y agoIs is fine, or suboptimal to the point of being impractical? Genuine question, how bad is this, if quanified?
- sanxiyn 7y agoIt is fine and practical.
- staticassertion 7y agoAdjacency matrices are trivial to implement in Rust. I leverage graphs constantly.
- tick_tock_tick 7y agoIt's slow.
- pornel 7y agoYou 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.
- Rusky 7y agoYou 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).
- BubRoss 7y agoIt doesn't need to be unsafe or unoptimal, just use indices into flat memory instead of pointers.
- AndyMcConachie 7y agoAs 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.
- steveklabnik 7y agoRust 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.
- 0xdead 7y agoI thought resources were freed when they went out of scope preventing any memory leaks in Rust.
- pornel 7y agoThey 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).
- Rusky 7y agoThat'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`.
- kinghajj 7y agoYou 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.