Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)
match or if/else?
Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple iflet enough, other times a match makes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.
How should errors be handled?
This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.
Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don’t care as much about the differences as you typically want to deal with them all in the same way when you are near to main).
Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper).
I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus… a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.
IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.
Precisely. I work in Python a lot, and almost all of our classes use mixins because there’s single inheritance rarely is that answer. And that’s basically just an abuse of inheritance and a trait system would probably be a better fit.
Depending on your language, your closest analogue is going to be interfaces. C# even has a where clause where you can restrict a generic type such that any type substituted must implements one or more interfaces. You can get quite a bit of trait like working there, from the function input side of stuff.
The biggest problem is, you can’t implement an interface for a type unless you have access to the type. So you’d have to really on wrapping types you don’t own to apply trait like interfaces to it.
And then there’s minor issues like, no such thing as associated types, or being able to specify constants in a definition. But you can usually work around that in a less nice way.
In my case, it was in Dart. Dart allows extending existing classes with new methods, but unfortunately this doesn’t allow implementing abstract mixins (which is the equivalent of Rust’s trait) on other types. Dart is in this weird middle where it’s not really strictly typed (it has dynamic, which is like the any type in TypeScript), but the compiler doesn’t allow ducktyping anyways.
Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)
Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple
if letenough, other times amatchmakes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.
Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don’t care as much about the differences as you typically want to deal with them all in the same way when you are near to main).
I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus… a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.
IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.
Precisely. I work in Python a lot, and almost all of our classes use mixins because there’s single inheritance rarely is that answer. And that’s basically just an abuse of inheritance and a trait system would probably be a better fit.
I recently caught myself trying to do traits in an OOP language. Failed spectacularly of course.
But it would be so much easier to read…
Depending on your language, your closest analogue is going to be interfaces. C# even has a where clause where you can restrict a generic type such that any type substituted must implements one or more interfaces. You can get quite a bit of trait like working there, from the function input side of stuff.
The biggest problem is, you can’t implement an interface for a type unless you have access to the type. So you’d have to really on wrapping types you don’t own to apply trait like interfaces to it.
And then there’s minor issues like, no such thing as associated types, or being able to specify constants in a definition. But you can usually work around that in a less nice way.
In my case, it was in Dart. Dart allows extending existing classes with new methods, but unfortunately this doesn’t allow implementing abstract mixins (which is the equivalent of Rust’s trait) on other types. Dart is in this weird middle where it’s not really strictly typed (it has
dynamic, which is like theanytype in TypeScript), but the compiler doesn’t allow ducktyping anyways.