3 ms·
Rust and C# is not that different after all. You're gonna have to fight with some more aggressive compile checks than what you're used to, but otherwise it shou
by capableweb 4y ago
Rust and C# is not that different after all. You're gonna have to fight with some more aggressive compile checks than what you're used to, but otherwise it should be relatively smooth sailing.
And Bevy (one Rust game engine) makes it very easy to ignore much of the problems of Rust, as the architecture (ECS) and the implementation Bevy has of it, hides a lot of "warts" that you would have to battle with otherwise.
Bevy makes it really easy to learn Rust, at least that's what I've found when I picked up Rust first.
- sergiosgc 4y agoC# is classic object-oriented, while Rust skips polymorphism. It takes a while to grasp how to properly design using traits with no polymorphism. The transition is far from simple. I happen to like Rust's choice, a lot, but it is a very different approach.
- capableweb 4y agoI was thinking more about the syntax in general. Maybe I'm over-simplifying because most of my time is spent working with Clojure, but Rust and C# syntax is to me very similar to each other (together with most C-like languages). But I agree, programming patterns are different enough to make it harder to make the jump I guess.
- RussianCow 4y agoSyntax is the easiest thing to pick up about a new programming language. Semantics, idioms, etc take far more time, and in that sense, C# and Rust are very different.
- capableweb 4y agoParent specifically mentioned syntax so I specifically talked about it...
- brundolf 4y agoTechnically traits are polymorphism (and you could argue Rust's enums are too), they just look differently than in classically object-oriented languages What Rust really skips is inheritance (although you can get partway there with trait dependencies), which I think is generally a good thing
- tialaramex 4y agoSpecifically Rust doesn't have implementation inheritance. The fact that [u8; N] and Vec<String> are both IntoIter doesn't imply they are somehow inheriting any common elements of their implementation, just that they both provide means to convert themselves into Iterators when needed. In Rust we could make a Mimic by composing a Chest, and a Monster, and then implementing any traits on the resulting composite object appropriately, passing through to an underlying object in some cases -- opening this "Chest" ought to cause its status as a Monster to be revealed right?. In languages with single inheritance we need to decide, is a Mimic a Chest? Is it a Monster? Maybe all Chests are Monsters? Maybe all Monsters are Chests? In languages with multiple inheritance we can inherit from both, but we might find that isn't what we wanted either and there are likely to be conflicts from such a web of heritability.