Comment by vlmutolo | Hacker News Reader

Comment by vlmutolo | Hacker News Reader

> The aspect of rust about which I am most deeply dubious is the heavy use of macros: they are a herald of rust's pedantry ("If you don't use these macros you are going to have to write a shit-ton of boilerplate code.")

The most-used, most-loved macros in Rust have nothing to do with Rust's "pedantry", but rather the programmatic derivation of business logic that would have been annoying to write.

Serde's Serialize and Deserialize macros are amazing for creating complex and correct logic for shuffling data into and out of various serialization formats.

Structopt's (and now clap's) macros for command line argument parsing make writing CLIs a piece of cake. Arguably this is just another form of deserialization. Still great, and unrelated to the fact that Rust is verbose and explicit.

I guess you could argue that something like the PartialEq derivation macro is only necessary because Rust forces you to explicitly declare how user-defined types compare to each other (<, >, =, etc.) But I think this is super reasonable, and if you accept that, then the macro just provides a shortcut to opt-into the code that most people might want, which is that structs will compare using the comparison functions of their inner fields.

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.

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).

Try to use Gtk-rs without the clone macro, and it will be lots of fun handling callbacks and widgets relationships.

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.

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.

once_cell does the same with a closure.

Improved const evaluation has also eliminated some uses of lazy_static.

Yeah, derive macros in rust are very similar to lombok and other annotation processing code generators in Java. Any of the trait function implementations could be written manually, but it saves work and makes it more robust to use the derive macro (or Lombok).

Macros get better as more people use them anyway, you build up a community knowledge of what the hell they generate. It turns out that unhygenic macros are really rather useful, if a bit dangerous.

Reply on news.ycombinator.com