Of course it has enumerations. It has had them from the get-go. After all, enums are a workaround to help deal with the shortcomings of a basic type system. You're bound to find them anywhere you find a basic type system, which certainly describes Go.
In fairness, there does seem to be some confusion floating around about the difference between enums and sum types, with some mistakenly calling sum types enums. Indeed, Go does not have sum types. This is what languages with more advanced type systems are bound to provide instead. Enums are pointless when you have a more expressive type system.
> Error handling requires lots of boilerplate.
What patterns are you seeing in other languages when it comes to error handling without the boilerplate?
Certainly there are other languages that provide shortcuts when not handling errors, but that's something else entirely.
The iota trick is not an actual enumeration as traditionally defined.
If err != nil after every fallible function call pales in comparison to being able to choose your own error handling such as automatic bubbling or wrapping that you can do in other languages. Go gives you two options: explicit handle or implicit ignore. There is no other option. The if statements clog up code unnecessarily. Rust does a great job of error handling, but I’d argue that almost every other language including Java does errors better than Go.
Enumeration is traditionally defined as establishing a number of something. iota accomplishes just that. That is what it is there for. Same as every other language that supports enums.
Maybe you’re thinking of the new definition that has recently emerged from confused Rust users that’s just another name for sum types? That’s actually sum types, not enumeration, though.
Letting an error bubble up isn’t handling it. Still interested in seeing what other languages are doing to eliminate the boilerplate when handling errors. For some reason you forgot to speak to it…
Explanation for enumeration: the thing about enumeration is you can ensure that you do an exhaustive handling of all cases in a switch statement. If an enum changes in a future library version you can get a compile error wherever the enum is enumerated in code which helps you handle new cases due to new features in a library. Go can’t do that.
I will agree on Go having bad error handling. That is the one pain point for me. As for complaints about lack of syntactic sugar and anti-expressivity: that's a feature, not a bug.
Of course it has enumerations. It has had them from the get-go. After all, enums are a workaround to help deal with the shortcomings of a basic type system. You're bound to find them anywhere you find a basic type system, which certainly describes Go.
In fairness, there does seem to be some confusion floating around about the difference between enums and sum types, with some mistakenly calling sum types enums. Indeed, Go does not have sum types. This is what languages with more advanced type systems are bound to provide instead. Enums are pointless when you have a more expressive type system.
> Error handling requires lots of boilerplate.
What patterns are you seeing in other languages when it comes to error handling without the boilerplate?
Certainly there are other languages that provide shortcuts when not handling errors, but that's something else entirely.