4 ms·
Good article but it somehow suggests that because there is no garbage collection you would need to fight the borrow checker. This is not fully true because you
by Klasiaster 6y ago
Good article but it somehow suggests that because there is no garbage collection you would need to fight the borrow checker. This is not fully true because you could put your data in a Box (so that it is stored on heap instead of the function's stack) and you can wrap it in a mutex with reference counting (Arc+Mutex or Rc+RefCell), which roughly gives you what garbage collection does. Also cloning can avoid solving the borrow-check puzzle if you don't need a shared state. Of course you would not want to pack your code with Arc+Mutex or data copying if performance matters, but it's fine for a beginner to start with when writing Rust and then learn to do the optimized borrow version a bit later when needed.
- pjmlp 6y agoIt doesn't give the productivity that GC allows for writing GUI code and UI designers. Imagine having JetPack Composer, SwiftUI, Qt designer, or WPF/UWP Blend in Rust.
- wwright 6y agoQt is actually a good example because C++ has a similar memory model to Rust (at least with respect to GC). The Qt solution was basically to give everything a “Cow” (copy on write) wrapper, and to use an event loop-based, somewhat manually-annotated GC for objects that want it. Rust could totally do the same thing, and you could probably make it way easier to use than the mess that is Qt.
- pjmlp 6y agoHaving dealt with Gtk-rs, and their current solution being the clone! macro, I am not so sure. Remember that not only is GUI development with proper tooling very interacting, instead of the FOSS alternatives of code-compile-check visually, there is also the whole eco-system of third parties selling component libraries, with no control how they get integrated into the component toolbox. So whatever solution one comes up with,it needs to be more productive than forcing users to scatter Rc<RefCells<>>, or fix their code that broke compilation, just because moving a widget on the GUI tree invalidated the borrow checker assumptions.