Polyglot Programming: TypeScript, Go, & Rust

Pointer, Struct & Error Gotchas



Polyglot Programming: TypeScript, Go, & Rust

Check out a free preview of the full Polyglot Programming: TypeScript, Go, & Rust course

The "Pointer, Struct & Error Gotchas" Lesson is part of the full, Polyglot Programming: TypeScript, Go, & Rust course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen discusses common language pitfalls, including value and pointer receivers in Go, differences between Go structs and Rust structs, and errors returning pointers when using Go. When using Rust, keep the following in mind: utilize traits for new behavior, the power of iterators, and the Option and Result on .map and iterator flat_map.


Transcript from the "Pointer, Struct & Error Gotchas" Lesson

>> 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. But if you didn't know those methods exist or what they do, it's a really hard problem to solve. So it's an either or. And so of course the whole goal of that last section was just to get us a little bit familiar with rust.

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. So as we program, our little CLI app, there will be times in which we are going to run into these. 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.

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. All right, so I did wanna also go over some like, hey, here are some language gotchas that I think are important.

So let's first talk with go. 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. A value receiver does not do anything with the statement.

So when I have f.thing equals five, your f does not get changed. So that is a value receiver. So that is just something you should always keep in your head. This can just massively screw you up, so just be careful. 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.

As I just a good thing to remember I've been bit by this multiple times. 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. More often than not, I think that an easy answer is default a locks to a pointer.

Unless if you really know why you don't need one. 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. If you need the mutated [INAUDIBLE] you gonna want some things here so don't get confused, all right?

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

Alright, so one more on go versus rock struct or rust structs. So I did actually go over this I believe in yeah, okay I did talk about this. 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.

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. This is backwards compared to rust. Just remember that, I know I've said it multiple times today. 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.

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. If the name does not match then you will have to use a little coal and do that just like Typescript. 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.

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.

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

It almost feels like they should add maybe a small piece of syntax just to do this for you, it'd be very fantastic, but it hasn't happened yet. So I feel like rust once you have the basics down, it is slower. But I feel like it's just less foot gantt, all right, everything is a little bit more on tracks.

Obviously, we did find that weird foo bar function depending on the order plus trade thing. But that's probably a rarity. Traits, make sure you're always thinking about traits if you're working with anything with the standard library, if you look up what traits it needs, if you implement those, you'll get a whole set of methods that are really nice.

And so always take some time. So you know how we use the From.String. You can also use the just From.String, and then you can call into on something. If you don't think it's not gonna cause any errors but into consumes the thing, so we'll go over that we'll actually use from instead of From.String and our little CLI application.

But, you always have to balance this idea of consuming the value versus simply just referencing the value and building a new object from it. So it's just like a little bit more overhead that you'd normally don't have to think about in other languages, all right? When you use something and go or TypeScript.

If I hand you something, I don't expect that thing to forever be gone. It's still in my possession as much as is in your possession. So it's nice iterators are really powerful, they're awesome. Don't forget about the dot map function as I showed you multiple times today how much better it is to use the dot map instead of like this whole handling error thinking about errors.

You can just flat map it if you're working with iterators, fantastic if your function returns an option you can dot map. On an option and return that and so that way you actually get the map option. It's pretty cool stuff.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now