Re unions:
replyhttps://github.com/golang/go/issues/76920
You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
Having worked a couple of greenfield go shops post generics, it’s still quite rare to find them in first party code. They’re just not that useful outside of library APIs. Proper algebraic data types would be a huge game changer.
replyDo it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.
replyGo is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding).
replyI wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.
They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.
replyThey were, very unfortunately, outsmarted by said too-clever programmers. As such I would like to request my enums and ternaries be returned to me. Trust me, they will not make a dent in the messes people have still managed to create.
replyTagged unions can be implemented in user code, you dont actually need language support to use them.
replyThis is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn't count.
replyYou can also add support for exhaustive switches on tags.
replyJust as a linter config though?
replyThe C++ committee said the same thing, and gave us std::variant. They are painful to work with and do not really deliver most of the benefits people want.
replyThat is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.
replydeleted
replyTagged unions are not union types. A union type is a supertype for any arbitrary collection of types, but a tagged union aka sum type is a single type with multiple data constructors, and does not require subtyping to be implemented.
reply