3 ms·

>The discussion opened to say that Result is better than the pattern used in Go You are trying to paint a false dichotomy between Rust's Result<T, error> and G

by awused 3y ago

>The discussion opened to say that Result is better than the pattern used in Go You are trying to paint a false dichotomy between Rust's Result<T, error> and Go's (T, error). In reality the dichotomy is between sum types (which Result is a very simple case of) and languages without sum types, of which Go is one of a very small set. The key difference is that Result is available as an option in Rust/Haskell/Ocaml/etc, and I'm free to not use Result if it's not the right fit, where in Go the only option is to use a product type. Result<A,B> and the ? operator are shortcuts for concisely handling the very common case of handling "A or B, but never both or neither." If your producer doesn't fit that, you're free to define your own sum type. In Go, you are simply unable to represent these and must cover all four cases (or eight, or sixteen, or thirty-two, etc, as the function grows in complexity). Nothing I'm saying is specific to Rust either, despite your appealing to conspiracies, and Rust's ideas are not new, not by decades. Haskell, Ocaml, Java, C++, typescript, etc, (even C with a bit of squinting) all have basic sum types and can encode "A or B, but never both or neither" and "A or B or both, but never neither" in their type systems and control flow in a way that Go cannot. Rust didn't pioneer the idea of a basic sum types, Go is just uniquely (among popular statically types languages from the last 50 years) incapable of representing them. >So, in other words: Dependent state puts the producer in control, while independent state puts the consumer in control and that there are pluses and minuses to each approach, with neither being better, just different tradeoffs...? No, this is complete nonsense. In Go, if I never write "return nonNilFile, nonNilError", the consumer cannot magic that into existence. Your entire position about languages being consumer controlled vs producer controlled is entirely nonsense. Consumers cannot rewrite the code of the functions they call.

randomdata 3y ago
The thing is, that very false dichotomy was painted before my time. I refuted it. And you have spent your time claiming to refute what I said, albeit using random tangents that don't pertain to anything, which must mean that you too want to paint the false dichotomy? That or you didn't bother to read anything and just hope and pray that if you say type system enough times someone will bite even though it is the most boring topic imaginable and, as such, nobody ever will.
- awused 3y ago
  >The thing is, the false dichotomy was painted before my time. I refuted it. No, it wasn't and you didn't. Result is one option among many in Rust which covers the common case with concise syntax, where (T, error) is the only option in Go. I am free to return a Success<T>, PartialSucceess<T + Error>, Failure <Error> in Rust/Java/C++/Ocaml/Typescript. I think you're operating on some profound misunderstandings about Rust, Haskell, Ocaml, Java, Typescript, C++, and even C. I don't think you're open to trying Rust, but maybe you'd be open to playing with std::variant in C++ or manually tagging unions in C, to see what those languages can do that Go cannot. Try writing a C++ function that returns std::variant between T, std:::tuple<T, Error>, and Error. That's only 3 cases, which Go cannot do.

by awused 3y ago

randomdata 3y ago

The thing is, that very false dichotomy was painted before my time. I refuted it. And you have spent your time claiming to refute what I said, albeit using random tangents that don't pertain to anything, which must mean that you too want to paint the false dichotomy? That or you didn't bother to read anything and just hope and pray that if you say type system enough times someone will bite even though it is the most boring topic imaginable and, as such, nobody ever will.

awused 3y ago
>The thing is, the false dichotomy was painted before my time. I refuted it. No, it wasn't and you didn't. Result is one option among many in Rust which covers the common case with concise syntax, where (T, error) is the only option in Go. I am free to return a Success<T>, PartialSucceess<T + Error>, Failure <Error> in Rust/Java/C++/Ocaml/Typescript. I think you're operating on some profound misunderstandings about Rust, Haskell, Ocaml, Java, Typescript, C++, and even C. I don't think you're open to trying Rust, but maybe you'd be open to playing with std::variant in C++ or manually tagging unions in C, to see what those languages can do that Go cannot. Try writing a C++ function that returns std::variant between T, std:::tuple<T, Error>, and Error. That's only 3 cases, which Go cannot do.