Finally, we can make our own types (or data structures)!!
This is supplementary/separate from the Twitch Streams (see sidebar for links), intended for discussion here on lemmy.
The idea being, now that both twitch streams have read Chapters 5 and 6, we can have a discussion here and those from the twitch streams can have a retrospective or re-cap on the topic.
This will be a regular occurrence for each discrete set of topics coming out of The Book as the twitch streams cover them
With Ch 4 on the borrow checker out of the way, chapters 5 & 6 feel like the “inflection point” … the point where we’re ready to actually start programming in rust.
Custom types, data structures, objects with methods, pattern matching, and even dipping into rust’s traits system and it’s quasi answer to class inheritance.
If you’re comfortable enough with the borrow checker, you can really start to program with rust now!
I personally didn’t think this content was difficult, though it prompts some interesting points and topics (which I’ll mention in my own comment below).
- Any thoughts, difficulties or confusions?
- Any quizzes stump you?
- Any major tips or rules of thumb you’ve taken away or generally have about using
structsandenums?
I want to highlight one of the more subtle-yet-important clarifications made in these 2 chapters: associated functions vs methods, and how method calls are just syntactic sugar for function calls.
Unlike in many other languages, there is no formal distinction (e.g. via separate keywords) between methods vs constructors vs property getters. The first parameter as well as the return type determine if a given associated function is “actually” a constructor or a method (etc.).
Personally, I find this incredibly elegant; it’s a form of “less is more” that gets out of my way when I’m coding while still allowing me to use all of the existing patterns that I know from elsewhere.
I’m not entirely sure I understand exactly what you mean here.
Do you appreciate it as an implementation design for the language (I do too)?
Or do you see some utility in being able to call
MyStruct::my_method(&my_var)… or both, cuz there’s something assuring in knowing the simple pattern underneath the syntactic sugar is there?
Bit of both, I suppose. Along with my own experience trying to deal with prototypes in JavaScript and how Python handles methods vs “bare” functions internally in terms of v-tables and “where” things exist in memory.
I imagine the fact that both of those are interpreted languages plays somewhat heavily into it.
With regards to being able to write
MyStruct::my_method(&my_var), it’s the one-two punch of “I can use that specific syntax to differentiate between ‘inherited’ methods that have the same name” and that the compiler doesn’t treat.method()calls any differently and just rewrites them as such when doing it’s job.Yea I’d imagine so too.