go-sumtype
Dev tools
static analysis linter
SHOW HN2017
How HN took it
1 positive, 4 neutral or asking, 0 mixed, 0 critical, out of 5 comments about the project. Thread score +0.13.
Idea: 1 for, 0 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Useful for catching missed cases when new variants are added.
From 3 comments
In our code, we have a closed interface type with many variants, not unlike an AST. We frequently add new variants to that interface. It is nice to have a tool tell us which…
burntsushi on HNThis looks very nice. I've been working with sum types (as far as they can be called that) in Go a lot recently, and it's frustrating how bad it is as algebraic data types in…
lobster_johnson on HN"I think that switching on types in Go is gererally a total anti-pattern." It's not. A thing to bear in mind is that this tool is checking interface types that are strictly…
jerf on HN
Fills a gap in Go's type system; compiler checks are better than none.
From 2 comments
Language-level sum types are something that I miss a lot when I'm writing Go. I find myself using this error-prone pattern whenever I'm trying to represent state: ``` type…
wyc on HNThis looks very nice. I've been working with sum types (as far as they can be called that) in Go a lot recently, and it's frustrating how bad it is as algebraic data types in…
lobster_johnson on HN
Objections
Switching on types in Go is an anti-pattern; interfaces with methods are better.
From 2 comments
I think that switching on types in Go is gererally a total anti-pattern. In case you need to handle errors, in the end the type doesn't matter at all for you. You are interested…
cube2222 on HNI made a similar comment on the reddit post. This seems like something handled better by interfaces. In my experience, whenever I end up writing a large type switch on an…
pbnjay on HN
Using a tool to bend Go toward other language features means fighting the language; use a language with sum types.
From 2 comments
Isn't trying to hack a language to have the type system you wish it had, rather than simply using the language you wanted in the first place, something of a futile exercise? If…
grabcocque on HNI think that switching on types in Go is gererally a total anti-pattern. In case you need to handle errors, in the end the type doesn't matter at all for you. You are interested…
cube2222 on HN
Requests
Detect sum-type interfaces automatically rather than requiring a marker.
From 1 comment
From the readme: > The go-sumtype command recognizes this pattern, but it needs a small amount of help to recognize which interfaces should be treated as sum types Why is this?…
infogulch on HN
Questions
Why does the tool need help identifying which interfaces are sum types?
From 1 comment
From the readme: > The go-sumtype command recognizes this pattern, but it needs a small amount of help to recognize which interfaces should be treated as sum types Why is this?…
infogulch on HN
Alternatives named
Rust enums and other languages with algebraic data types.
From 2 comments
Isn't trying to hack a language to have the type system you wish it had, rather than simply using the language you wanted in the first place, something of a futile exercise? If…
grabcocque on HNLanguage-level sum types are something that I miss a lot when I'm writing Go. I find myself using this error-prone pattern whenever I'm trying to represent state: ``` type…
wyc on HN
Haskell data types.
From 1 comment
Language-level sum types are something that I miss a lot when I'm writing Go. I find myself using this error-prone pattern whenever I'm trying to represent state: ``` type…
wyc on HN
Interface methods instead of type switches.
From 1 comment
I made a similar comment on the reddit post. This seems like something handled better by interfaces. In my experience, whenever I end up writing a large type switch on an…
pbnjay on HN