2 ms·

Yes, but it's also much more likely to result in a run-time failure. I'm not talking about memory safety here -- just the fact that Rust has (Algebraic Data)/Su

Yes, but it's also much more likely to result in a run-time failure. I'm not talking about memory safety here -- just the fact that Rust has (Algebraic Data)/Sum Types[1]. Of course these kind of "want" pattern matching, but it's not an absolute requirement. Having ADTs/Sum types will improve the reliability of your software immensely just by being available. It's truly absurd just how much work they can do: They can replace "null", they can ensure that there are no surprises in a state machine where some state carries over unexpectedly, etc. etc. [1] Not higher-kinded, but that's probably a distraction for the point I'm making.

ilovecaching 8y ago
Agreed. You could encode valid state transitions phantom types, for example. Go's weaker type system means it has less power to encode was is and is not correct program behavior.
rhodysurf 8y ago
Yes I know. I love Sum types, and I love Trait oriented programming. And I definitely miss sum types in Go and C++. If C++ had sum types and no header files that would probably hit my (very subjective) sweetspot. Tangent: I wish Rust had optional chaining like swift, which I know is a limitation due to Option just being a normal sum type. Having to pattern match every optional is burdensome
- Quekid5 8y ago
  Heh, I was actually alluding to C++ with the pattern matching thing. Std::variant<> is actually a bona fide sum type, but using it is horrendous because of the lack of pattern matching. You can use the the "cppreference overloaded"[1] trick to sort-of do basic pattern matching of the outer constructor, but it's still not particularly well supported by compilers. [1] I'm using this as a proxy name for a trick I saw on cppreference where you can (via template tricks, why not?) write code very similar to pattern matching, but it's ultimately quite simplistic and brittle.
  - rhodysurf 8y ago
    Ahhh ok I gotcha now. To be honest I have not used std::variant yet as I am stuck on C++11 at work. I agree though at some point there is a limitation with no pattern matching like you have in rust

ilovecaching 8y ago

Agreed. You could encode valid state transitions phantom types, for example. Go's weaker type system means it has less power to encode was is and is not correct program behavior.

rhodysurf 8y ago

Yes I know. I love Sum types, and I love Trait oriented programming. And I definitely miss sum types in Go and C++. If C++ had sum types and no header files that would probably hit my (very subjective) sweetspot. Tangent: I wish Rust had optional chaining like swift, which I know is a limitation due to Option just being a normal sum type. Having to pattern match every optional is burdensome

Quekid5 8y ago
Heh, I was actually alluding to C++ with the pattern matching thing. Std::variant<> is actually a bona fide sum type, but using it is horrendous because of the lack of pattern matching. You can use the the "cppreference overloaded"[1] trick to sort-of do basic pattern matching of the outer constructor, but it's still not particularly well supported by compilers. [1] I'm using this as a proxy name for a trick I saw on cppreference where you can (via template tricks, why not?) write code very similar to pattern matching, but it's ultimately quite simplistic and brittle.
- rhodysurf 8y ago
  Ahhh ok I gotcha now. To be honest I have not used std::variant yet as I am stuck on C++11 at work. I agree though at some point there is a limitation with no pattern matching like you have in rust