> (not that someone can't be both, of course)

Indeed! I've been writing Go code daily for years. My open source life is just a bit more consumed by Rust these days. :-)

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? Have you tried detecting sum types automatically? Maybe some heuristics like: package-level declaration of the interface, has an unexported method, has more than one type that implements it, maybe also the interface itself is exported.

It seems unwise to do exhaustiveness checks automatically on an interface that "might" be a sum type. The declaration is a single line and has the benefit of being completely unambiguous.

> (not that someone can't be both, of course)

The Go vs Rust narrative seems to have thankfully mostly gone away (although I'm sure it will never die out completely). The areas that they're targeted and the things that they are best for have now become clearer to the community at large, and they don't necessarily overlap that much.

That said, I don't use either of them at work, so I'd interested to hear a counter-argument.

> The Go vs Rust narrative seems to have thankfully mostly gone away

I am not aware of that. Has something changed recently? Though IMO Rust's strength could lead interesting usage in Data processing/analytics platform like Hadoop/Spark etc as opposed to Go like web services.

"Go vs. Rust" was initially only a thing because 1) Google initially positioned Go as a systems programming language, 2) early prototypes of Rust were very Go-like (with both a garbage collector and segmented stacks), and 3) web developers who were already used to seeing Chrome vs. Firefox found it an easy conceptual extension. But Go hasn't been marketed as a systems language for a long time and Rust removed all its Go-like features years ago; the "Go vs. Rust" that we still see is just residual fallout.

It's funny, as a Go and Rust fan, they're still in the same space to me conceptually.

I'm sticking with Go at the moment because moving my shop to Rust is quite difficult (for varying reasons), and because Go offers a nice compromise on ease and power. However i miss no-null types so bad. All that compile-time information is amazing.

I really hope Go adopts some features from Rust.

What are the areas that they target? I'm not too familiar with the communities surrounding either language.

Go tends to be more Web related - back end services communicating over networks, etc. It's taken over things that in the past would often have been done in things like Python but as scales increase performance becomes more important. Google's backend web services is teh classic example of usage.

Rust is more in the C/C++ role - 'systems programming'. This leans more towards things like command line tools, system daemons, OS kernels, embedded work on small processors etc. Doing performance intensive tasks in Firefox is probably Rust's most well known application.

That's not say that there are overlap areas where they can't both work well, but those aren't so much the areas of emphasis.