This is, of course, where this comes from you've seen this if you've reviewed anyone's Go code, you've probably seen this 1000 times in your lifetime. If you don't have that it just simply makes it harder, all right? Because you have to construct an empty foo to return it back and that's probably not what you want to do. But you get the idea, so this is beautiful this is hurts my emotions a little bit, all right? Now that we got that errors, you may encounter errors remember whenever we have errors and things like that in Go, just remember if you have a pointer it's really easy to do this whole return nil error situation. And you can even enter mix them just like TypeScript where you have named ones and unnamed ones or implicit ones I'm not sure what the technical name for it is. If the name does not match then you will have to use a little coal and do that just like Typescript. Whereas with rust this does work even though these properties are backwards because of course it uses the name of the variable To map it over. It's just such an easy way to get owned right like you just don't you just don't want that, it's just not fun. Just remember that, I know I've said it multiple times today. This is a list initializer, y will be equal to x, and x will be equal to y because it goes in order of your struct properties. So if you have a GoLangstruct and has y than x we actually talked about this, all right? And then you have a constructor method called new struct.
So I did actually go over this I believe in yeah, okay I did talk about this. Alright, so one more on go versus rock struct or rust structs. Again, I haven't investigated any level to it, so I can't tell you exactly why or how that's happening, but it does, so. There we go there is perf wins I've read at least read articles I've never personally tested myself but apparently using value receivers even though the struct is copied can actually have some set of performance wins. If you need the mutated you gonna want some things here so don't get confused, all right? If you're gonna be having errors, you pretty much need one or else you have to return blank versions of it, empty versions of it.
Unless if you really know why you don't need one. More often than not, I think that an easy answer is default a locks to a pointer. So I tend I know there's like 17 rules to why you should use a pointer and go and when you shouldn't use a pointer. As I just a good thing to remember I've been bit by this multiple times. Instead, a pointer receiver on the other hand will change that answer because you are manipulating the thing that is pointing to yours as opposed to a copy of what you had. This can just massively screw you up, so just be careful. So that is just something you should always keep in your head. So when I have f.thing equals five, your f does not get changed. A value receiver does not do anything with the statement. I did mention this earlier, all right? So if you have a struct foo, and you have a thing, you can have what is referred to as a value receiver or a pointer receiver. All right, so I did wanna also go over some like, hey, here are some language gotchas that I think are important. And so we should see how these things really play out in practical rust as opposed to these simple operations which often you don't actually run into problems in the simple ones. And I've even pre-planned it as long as I don't screw it up and program it correctly like a massive ownership problem that should happen at the end. So as we program, our little CLI app, there will be times in which we are going to run into these. So okay, we ran into pretty much virtually no ownership problems because we're just passing values, all right? We wouldn't ever hold on to things. And so of course the whole goal of that last section was just to get us a little bit familiar with rust. But if you didn't know those methods exist or what they do, it's a really hard problem to solve.
> I mean, I don't know, rust was pretty cool, all right? Once those methods exist, it's actually a fairly trivial problem to solve. Transcript from the "Pointer, Struct & Error Gotchas" Lesson
0 kommentar(er)
