Call me spoiled, but sum types are the best, especially when it comes to static analysis. I really miss Rust's tagged union enums with exhaustivity checking when working on my Go projects. Working around the lack of sum types is possible, yes, but it is not as safe nor as ergonomic as simply having them.Svip wrote: βSat Dec 30, 2023 7:39 amAs someone who maintains a large Go codebase, the lack of sum types isn't as big of a deal, once you've learnt to "program around them". Sum types are - at least in imperative languages - a relatively new feature. Honestly, I didn't find the lack of generics frustrating either, but now they are there. If Go adds sum types, it would also be a welcome addition. But it is getting harder to keep the Go 1 compatibility promise in such cases. Though their loop iteration backwards compatibility solution could bode well for potentially breaking changes in the future, so who knows. But I love that Go - as a language - is relatively small; it's possible to keep the entire grammar in your head.
It's worth noting that I mostly end up wanting them when interfacing with code that relies on them, such as LSP. I'm writing a Lua language server in Go and the protocol is full of this-or-this-or-that, which is tedious to work with without tagged unions.
I completely agree in regards to Go's simplicity - it's one of the primary reasons I love the language so much.