Rust Q&A

[00:00:00]
>> What benefits are there for macros over functions? Honestly, it's mainly just a matter of convenience. Because they let you do more things than functions do functions, you give them the arguments, and that's all they get to work with. For example, in this print line call, I'm giving it as many different arguments as I want.

[00:00:18]
I always have to give it the string literal that it's going to be interpolating. And then I can give it as many different arguments as I want. And at compile-time, rust is able to turn these into other function calls. Normally, as we will see later on when we define our own functions, when you define a rust function, you have to fix the number of arguments.

[00:00:38]
You can't say this can take as many arguments as you want, so that's one of the things that macros let you do. There are some other more advanced things that we won't get into in this course that you can do with macros. But I guess the short answer is that macros are sort of strictly more powerful than functions in every way except for one.

[00:00:57]
Which is that a function you're allowed to pass around, you can have first-class functions in rust. You cannot pass macros around. Because really what this exclamation point is saying is at compile-time, the rust compiler is going to take this whole statement right here, this whole line and break it down and run some code and turn it into a series of function calls.

[00:01:15]
So you can't really pass that around because that's not really a thing it's just sort of like a way to let you write something like syntax sugar at compile-time.
>> Yeah, so are there performance differences between macros versus functions?
>> Great question. Are there performance differences between macros versus functions?

[00:01:32]
Yes at compile time but not at runtime. So, because a macro is just going to at compile time the term is expanded it gets expanded into these series of function calls. It's no different than if you'd written those function calls by hand as far as runtime performance is concerned.

[00:01:45]
But because it has to do that expansion work at compile time, macros are one of the things that can make your compile times longer in rust, depending on the complexity of the macro and how many you're using and so forth.
>> So using less macros would make it compile faster.

[00:02:01]
>> All else being equal, yeah. Using fewer macros would not improve your compile times. But to be honest, that's not a common remediation macros tend to, unless you're really using a lot of them, they tend not to be the main culprit in compile times, in my experience.
>> Questions around the point of immutable variables I'm not sure if you want to get into that or not.

[00:02:25]
>> I mean, the point of them is essentially, it's just good programming practice to default to immutability because they're less error-prone. If I didn't intend to reassign this to x if I thought okay, x is defined this way. And if I have a whole big chunk of code after this, I want to know whether or not x might be changing anywhere in there.

[00:02:43]
And if I define it with let I can know, yeah 100% confidence, there's no chance that this was changed because the compiler wouldn't have let me. Whereas if I say let mut, I now have more things to check because I can say, well, hang on, x could have changed at any point in these steps.

[00:02:55]
I need to sort of go audit that to try and figure out what might have changed.
>> You've talked about rust being a static language, right? Because there's questions around dynamic versus static.
>> So yeah, so rust is definitely a static type check language. There is a keyword called dyn, D-Y-N, but it's relatively advanced use case, and we're not going to get into it in the course of this course.

[00:03:18]
But it doesn't really do what you might guess based on the name if you're thinking about it in terms of static versus dynamic. But yeah, like c plus plus or Java, Rust is just a type-checked language there's no runtime dynamic types.