Let's write a macro in Rust
hackeryarn.com
Let's write a macro in Rust
1–10 of 50 posts
Re: Let's write a macro in Rust
#2[deleted]
Re: Let's write a macro in Rust
#3They should try writing a spellchecker first, I found the article difficult to read because of the high frequency of typos.
Re: Let's write a macro in Rust
#4They should try writing a spellchecker first, I found the article difficult to read because of the high frequency of typos.
The spelling mistakes seems almost intentional. I've noticed that a lot of publications that used to publish obvious AI slop now are doing the same, I'm guessing it throws off some "LLM detectors" or similar.
Re: Let's write a macro in Rust
#5Having done some Rust macros, the entire thing is such a huge hidden wart. Even very simple meta-programming in Rust need to be in their separate crate and has to use very complex syntax and invocation.
Also the whole "don't write macros" is such a hilarious statement given that entire Rust ecosystem is built on them.
Re: Let's write a macro in Rust
#6Having done some Rust macros, the entire thing is such a huge hidden wart. Even very simple meta-programming in Rust need to be in their separate crate and has to use very complex syntax and invocation. Also the whole "don't write macros" is such a hilarious statement given that entire Rust ecosystem is built on them.
I agree Rust macros are cursed in many different ways but
> given that entire Rust ecosystem is built on them.
I don't think the people saying "don't write macros" are the same people building an entire ecosystem on top of them
The iced crate has virtually zero macros by design.
Re: Let's write a macro in Rust
#7Having done some Rust macros, the entire thing is such a huge hidden wart. Even very simple meta-programming in Rust need to be in their separate crate and has to use very complex syntax and invocation. Also the whole "don't write macros" is such a hilarious statement given that entire Rust ecosystem is built on them.
Eh. I agree there's complexity in them, and that a lot of the ecosystem indirectly use them because of derive macros, but I wouldn't call it a wart, and the "syntax" for writing proc macros isn't that bad if you use the syn/quote crates. I agree that decl macros usually make me sigh and open the docs though
Re: Let's write a macro in Rust
#8Bjarne Stroustrup said "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". The same is true of Rust macros. When you need them they're awesome, but you should almost never need them - add a new macro as a very last resort.
Re: Let's write a macro in Rust
#9Having done some Rust macros, the entire thing is such a huge hidden wart. Even very simple meta-programming in Rust need to be in their separate crate and has to use very complex syntax and invocation. Also the whole "don't write macros" is such a hilarious statement given that entire Rust ecosystem is built on them.
It is its own can of worms, and maybe it is due to me using the language on and off since 1992, but I find what is possible in C++23, much easier for metaprogramming as the few times I had to understand trying to implement Rust macros.
C++26 reflection will make this much easier, without having to depend in stuff like the syn crate.
I wonder if going with two macro systems, each with its own syntax and approach, was such a good idea.
Re: Let's write a macro in Rust
#10I like using or exposing macros when appropriate. They can simplify messy syntax, or prevent repetitions not allowed by the compiler directly. I can't get the syntax for writing them to stick. So, I am happy with letting LLMs handle this.
Sometimes the macros are for large chunks of code that uses a different type in a key place, or sometimes they're for cleaning up verbose function calls that will be made multiple times, so the important parts (e.g. the params) are obvious, instead of being mixed with boilerplate. In general, they're nice for papering over boilerplate. In particular, there's a pattern in embedded that involves a long expression with `try_into().unwrap()` for parsing bytes that I have a macro for. And another for managing RefCell>> locks.
I prompt the LLM with the working, but repetitive or boilerplate-laden code, and it macros it: "Please write a macro that stops the repetition in this code block: ```rust ```. Here's a example of calling it: `do_thing!(a, b, c)`
Works every time!