5 ms·
> Rust: [...] A over active amount of fans, that do not understand its complex. No. We understand it is complex. We also understand why: memory management is c
by kaoD 10y ago
> Rust: [...] A over active amount of fans, that do not understand its complex.
No. We understand it is complex. We also understand why: memory management is complex in and of itself, but RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language.
- qznc 10y ago> RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language D agrees with the "everything" part. D wants to give you options, so you can use GC/RC/manual where appropriate. Sadly, I have not found the time to wrestle with the Rust borrow checker myself. I still have doubts if it is worth it. For example, assume you write a graph data structure. To pass the lifetime analysis, you have to store the nodes in some background store vector. If you want to free/reuse memory of nodes, Rust essentially requires you to write a garbage collector for the nodes yourself. Afaik there are plans to add an optional GC to the standard library? So ultimately, D and Rust converge to the same point from different angles. Both want all the options. Rust started from safe manual and gains options. D started with safe automatic and gains safety for manual.
- kaoD 10y ago> D wants to give you options, so you can use GC/RC/manual where appropriate. Again, those options are what I listed as the wrong approaches. Manual = ad-hoc memory management. There's an additional option only present in Rust: automatic memory management via static analysis. Rust does not allow manual memory management at all unless writing unsafe code. Unlike Rust, D code with memory allocations is either GC'd or unsafe. Just to make it clear: the borrow and lifetime checkers are not manual memory management. Lifetimes are just hints for the compiler to do its automatic memory management at compile time. > ultimately, D and Rust converge to the same point Definitely not.
- qznc 10y ago> the borrow checker is not manual memory management Ok, we disagree on the terminology here. I would consider that manual, because it looks the same in C++. Rust only has the static analysis to weed out all the unsafe/broken code.
- deleted 10y ago[deleted]
- kibwen 10y ago> I would consider that manual, because it looks the same > in C++ Many also consider RAII in C++ to be "automatic memory management". Other than agreeing that C is manual and Java is automatic, terms are failing us here. :) In the Rust community, instead of trying to argue whether or not Rust is manual or automatic (or "safe manual memory management", or "static automatic memory management", or etc.), we tend to just say "in Rust, you do need to think about memory management, but you don't need to worry about memory management". :P
- kibwen 10y ago> Afaik there are plans to add an optional GC to the > standard library? This is incorrect. There are some far-future plans to add GC hooks to the language to allow it to interoperate with external GCs (mostly motivated for Servo to use with Spidermonkey, Firefox's Javascript engine), but there will never be a GC implementation shipped with the stdlib itself.
- qznc 10y agoOk, so only library-GC like https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc ?
- kibwen 10y agoYes, Manish there is a Servo dev who spends some of his time thinking about how Rust could support external GCs. I believe his goal there is to write a library that's more-or-less analogous to the basic Boehm collector for C, as a proof-of-concept.
- p0nce 10y ago> I still have doubts if it is worth it. It is definately worth it to have such ownership. This style was discovered in C++ and made better in Rust. A leaner version of this is the C++11 version, which has std::unique_ptr and raw pointers. Very popular in today's C++.