5 ms·

GC, manual malloc/free, or lifetimes and macros: choose one. Rust would be miserable to use without macros. There's so much ceremony and friction to ensure memo

GC, manual malloc/free, or lifetimes and macros: choose one. Rust would be miserable to use without macros. There's so much ceremony and friction to ensure memory safety that you need a powerful macro system to cut through it sometimes. If you don't like the macros then you can always use a managed GC language that gives the same safety guarantees at a performance cost.

ameliaquining 5y ago
Wait, most uses of macros in Rust don't have much to do with memory safety. RAII and borrow-checking don't rely on macros at all. Most features of, e.g., serde would work the same way in a garbage-collected language. The primary exception that comes to mind is pin_utils::pin_mut, which is a macro primarily because of the somewhat circuitous route by which async came to Rust. If the language had been designed to support async from the beginning, I suspect that it probably would have been built-in syntax (assuming it didn't avoid the need for such an API entirely by using a different design).
- pjmlp 5y ago
  Try to use Gtk-rs without the clone macro, and it will be lots of fun handling callbacks and widgets relationships.
  - ameliaquining 5y ago
    I wouldn't call this kind of macro idiomatic in non-GTK code. Reference counting is mostly used only occasionally in Rust code, and so the boilerplate cost of adding another local variable when giving a closure its own reference-counted pointer is outweighed by the maintainability cost of introducing a macro. gtk-rs is different because it pervasively uses Rust bindings to a non-Rust-based memory management system based on reference counting and interior mutability, kind of like if everything was wrapped in Rc<RefCell<T>>. In that scenario, yeah, adding another local in front of every closure capture sounds like a pain. If most Rust code were like this, I suspect that something like glib::clone would be added as built-in syntax.
- zarzavat 5y ago
  For instance one of the most popular crates is the lazy_static macro without which it is hard to define global state. I also tend to define quite a few helper macros in my Rust code to keep clean.
  - pornel 5y ago
    once_cell does the same with a closure. Improved const evaluation has also eliminated some uses of lazy_static.

ameliaquining 5y ago

Wait, most uses of macros in Rust don't have much to do with memory safety. RAII and borrow-checking don't rely on macros at all. Most features of, e.g., serde would work the same way in a garbage-collected language. The primary exception that comes to mind is pin_utils::pin_mut, which is a macro primarily because of the somewhat circuitous route by which async came to Rust. If the language had been designed to support async from the beginning, I suspect that it probably would have been built-in syntax (assuming it didn't avoid the need for such an API entirely by using a different design).

pjmlp 5y ago
Try to use Gtk-rs without the clone macro, and it will be lots of fun handling callbacks and widgets relationships.
- ameliaquining 5y ago
  I wouldn't call this kind of macro idiomatic in non-GTK code. Reference counting is mostly used only occasionally in Rust code, and so the boilerplate cost of adding another local variable when giving a closure its own reference-counted pointer is outweighed by the maintainability cost of introducing a macro. gtk-rs is different because it pervasively uses Rust bindings to a non-Rust-based memory management system based on reference counting and interior mutability, kind of like if everything was wrapped in Rc<RefCell<T>>. In that scenario, yeah, adding another local in front of every closure capture sounds like a pain. If most Rust code were like this, I suspect that something like glib::clone would be added as built-in syntax.
zarzavat 5y ago
For instance one of the most popular crates is the lazy_static macro without which it is hard to define global state. I also tend to define quite a few helper macros in my Rust code to keep clean.
- pornel 5y ago
  once_cell does the same with a closure. Improved const evaluation has also eliminated some uses of lazy_static.