Re:The struggle with Rust
by rbehrends on Tuesday January 24, 2017 @12:21PM
(#13473355)
Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.
[ Parent
| on HN ]
Then use https://github.com/Manishearth/rust-gc if you're willing to pay the price of a GC (still experimental). Or better, stick to a GC'ed language.
If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in.
Use the right tool for the job.
Re:The struggle with Rust
by Manishearth on Tuesday January 24, 2017 @12:56PM
(#13473722)
(Please don't use rust-gc, it's more of a proof of concept. I mean, it works, and some folks do use it, but Rc + Weak are probably better options)
> If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in.
That's exactly the point that I made in my original comment?
Sorry, HN isn't great at keeping track who's who on a comment tree.
Re:The struggle with Rust
by galangalalgol on Wednesday January 25, 2017 @07:10PM
(#13487482)
Does GC imply memory safety? Use after free and dangling references probably can't happen, but I have never heard of a GC supplying cross thread memory safety. The borrow checker does.
Memory safety in multi-threaded programs is not a hard problem once you have GC. Eiffel solved it decades ago. The JVM also has a weak form of memory safety; it does not preclude data races, but the VM cannot crash as the result of a data race.