21–30 of 50 posts
Having 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.
They should try writing a spellchecker first, I found the article difficult to read because of the high frequency of typos.
I learned a lot regardless and I'm adding this to my blogroll.
Now apologies for the aside—and I know I'm likely wading into a very expansive topic and reducing it down to something simple—but why in Rust, if the types are known:
struct Song {
title: String,
artist: String,
rating: i64,
}
Song::new("Hate Me".to_string(), "Blue October".to_string(), 9)
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros. Now apologies for the aside—and I know I'm likely wading into a very expansive topic…
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros. Now apologies for the aside—and I know I'm likely wading into a very expansive topic…
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros. Now apologies for the aside—and I know I'm likely wading into a very expansive topic…
There is the exception of Deref. If the function requires type A, and you pass it type B, which Derefs into type A, the compiler will Deref it for you. But that is zero cost and panic free, whereas allocating (and copying) an owned type from a reference isn't. In Rust you have to be explicit.
Anyway, using String in function signatures is most often not the best choice. If you will internally be required to use a String, it's better to ask for a type "impl Into", you'd call into() inside your function. And in the most common case, where you require a &str or can convert to your type from it, the best choice is an "impl AsRef" and you can call as_ref() on it to get a str reference, which you can wrap in a Box, Rc, Arc, String, or your custom type, or pass it directly to other functions. All of those, Box, Rc, etc implement both traits.
Using impl Trait, you avoid having to declare generic parameters.
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros. Now apologies for the aside—and I know I'm likely wading into a very expansive topic…
If you don't see the gain, maybe Rust is not the right language for your use-case.
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros. Now apologies for the aside—and I know I'm likely wading into a very expansive topic…
https://groups.google.com/a/chromium.org/g/chromium-dev/c/EU...