3 ms·

That’s fascinating, what would you say obscures clarity? Go: https://go.dev/play/p/s4TTZeo7Gse https://go.dev/play/p/s4TTZeo7Gse Rust: https://play.rust-lang.

That’s fascinating, what would you say obscures clarity? Go: https://go.dev/play/p/s4TTZeo7Gse https://go.dev/play/p/s4TTZeo7Gse Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8276ff4430c3f5b344f3ddde3c5e4930 https://play.rust-lang.org/?version=stable&mode=debug&editio... For me, i reckon the Go type machinery is more verbose in this case, e.g. the isShape method to tag Circle as a shape - that just feels awkward to me. The cyclomatic complexity is identical for both though.

skohan 4y ago
Yeah exactly, imo the way the Go version requires you to declare an interface, in this case with a no-op method essentially acting as a tag, and declare conformance on your types is quite noisy and feels like a hack. Also I prefer with Rust-style sum types that the declaration happens in one place. In the Go version your Shape types could be scattered around all over the place, which makes it harder to parse and understand if you're reading unfamiliar code.
preseinger 4y ago
This Go code is wildly non-idiomatic. Type assertions via `.(type)` are a tool of last resort, not something that an application developer should turn to as a solution to a problem, and certainly not post-1.18, which permits generics. edit: e.g. https://go.dev/play/p/wDO5J8CElSC https://go.dev/play/p/wDO5J8CElSC
- CraigJPerry 4y ago
  Hey thanks for sharing this, I think this has lost track of the problem though, remember we're looking for the alternative to rust's: enum Shape { None, Circle(radius: usize), } In your version we've lost the Shape concept, to make it more explicit, what's the idiomatic go version of: enum Shape { Circle(usize), Rectangle{length: usize, breadth: usize}, } https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=03c26eceee80168ffd69518aeefcc8e6 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - preseinger 4y ago
    There is no way to express an enum whose possible values are of different types. In Go code will typically "offer" concrete types, and "accept" abstract interfaces. Abstractions over concrete types are expressed by consumers who want to operate on those types, rather than producers who provide implementations of them. So your Shape would probably end up an interface defined by whatever consuming code wanted to treat Circles and Rectangles equivalently.

skohan 4y ago

Yeah exactly, imo the way the Go version requires you to declare an interface, in this case with a no-op method essentially acting as a tag, and declare conformance on your types is quite noisy and feels like a hack. Also I prefer with Rust-style sum types that the declaration happens in one place. In the Go version your Shape types could be scattered around all over the place, which makes it harder to parse and understand if you're reading unfamiliar code.

preseinger 4y ago

This Go code is wildly non-idiomatic. Type assertions via `.(type)` are a tool of last resort, not something that an application developer should turn to as a solution to a problem, and certainly not post-1.18, which permits generics. edit: e.g. https://go.dev/play/p/wDO5J8CElSC https://go.dev/play/p/wDO5J8CElSC

CraigJPerry 4y ago
Hey thanks for sharing this, I think this has lost track of the problem though, remember we're looking for the alternative to rust's: enum Shape { None, Circle(radius: usize), } In your version we've lost the Shape concept, to make it more explicit, what's the idiomatic go version of: enum Shape { Circle(usize), Rectangle{length: usize, breadth: usize}, } https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=03c26eceee80168ffd69518aeefcc8e6 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- preseinger 4y ago
  There is no way to express an enum whose possible values are of different types. In Go code will typically "offer" concrete types, and "accept" abstract interfaces. Abstractions over concrete types are expressed by consumers who want to operate on those types, rather than producers who provide implementations of them. So your Shape would probably end up an interface defined by whatever consuming code wanted to treat Circles and Rectangles equivalently.