A lot of people said the same about generics, and some even still do. I could barely stand Go before generics, and still don't think they go far enough.
From my experience, things I think Go could really benefit from, like I believe it has benefited from generics:
* A way to implement new interfaces for existing types and type constraints for custom types, like `impl Trait for T`. This would obsolete most uses of reflection in the wild, in a way generics alone haven't. This isn't about syntax, it's about an entirely different way to associate methods to types, and with both Go and Rust being "data-oriented" languages, it's weird that Go is so limited in this particular regard. It has many other consequences when combined with generics, such as ...
* Ability to attach receiverless methods to types. Go concrete types may not need associated methods like "constructors", but generic types do, and there's no solution yet. You can provide factory functions everywhere and they infect the whole call graph (though this seems to be "idiomatic"), or make a special method that ignores its receiver and call that on a zero instance of the type, which is more hacky but closer to how free functions can be resolved by type. There's no reason this should be limited to constructors, that's just the easiest example to explain, in Rust associated methods are used for all kinds of things. Speaking of which...
* `cmp.Ordered` for custom types. Come on people. We shouldn't still have this much boilerplate to sort/min/max custom types, especially two full years after generics. The new `slices.SortFunc()` is the closest we've ever come, and it's still not associated with the type. We would basically get this for free if both of the above points were solved, but it's also possible we get something else entirely that solves only ordering and not e.g. construction or serialization.
* Enums, especially if the need for exhaustiveness checking could be balanced with Go's values of making code easy to evolve later. When I need them, I use the `interface Foo { isFoo() }` idiom and accept heap boxing overhead, but even the official `deadcode` analysis tool still to this day does not recognize this idiom or support enough configuration to force it to understand. The Go toolchain could at the very least recognize idioms people are using to work around Go's own limitations.
If we had solutions to these problems, I think most Go folks would find enough value in them that they would still be "Go". In fact, I think people would have an easier time consolidating on a new standard way to do things rather than each come up with their own separate workarounds for it.
This is where I feel "The code I write, is going to look like the code written by most other on my team" the least, because that's only true when a Go idiom has some official status, it's not nearly as true for workarounds that the Go team has not yet chosen to either endorse or obsolete.
> From my experience, things I think Go could really benefit from [...] Enums
Obviously it already benefits from enums.
type E int
const (
A E = iota
B
C
)
Which, once you get past the superficiality of syntax, is identical to, say, what you find in C.
enum E {
A,
B,
C
}
Enums are just a numbering mechanism, after all. No different than hand numbering constants, but without the need to put in the manual effort. Enums kind of suck, though. Are you sure any language actually benefits from them (as compared to better alternatives)?
> especially if the need for exhaustiveness checking
It is true that gc doesn't make any effort to determine how the enums are used, but if it were to it would be a warning like as is seen in many C compilers. As enums are values, not a type, it's not a fault to use them "inappropriately". While it may be all fine and dandy to add such warnings to gc, the Go team has taken a hard line stance that warnings have no place in the compiler. Of course, the external analysis tools like you speak to can still be used to provide these warnings for you. All the information you need is there.
But it seems what you really want is a more expressive type system – specifically sum types. Then you would be able to describe how you expect identifiers to be used without resorting to using generated number values as placeholders. Enums are just a hack to work around a limited type system anyway. If you are going to improve the type system in order to gain improved compilation constraint, you don't need enums anymore.
Rust doesn't have enums and nobody has ever noticed. Hell, many are even somehow convinced it has enums – but it does not. It provides tag-only unions (with, optionally, fully tagged unions) instead. Seemingly that is what you really want in Go as well. And fair enough. It is undeniably the better solution, but at the cost of being more complex to implement.
From my experience, things I think Go could really benefit from, like I believe it has benefited from generics:
* A way to implement new interfaces for existing types and type constraints for custom types, like `impl Trait for T`. This would obsolete most uses of reflection in the wild, in a way generics alone haven't. This isn't about syntax, it's about an entirely different way to associate methods to types, and with both Go and Rust being "data-oriented" languages, it's weird that Go is so limited in this particular regard. It has many other consequences when combined with generics, such as ...
* Ability to attach receiverless methods to types. Go concrete types may not need associated methods like "constructors", but generic types do, and there's no solution yet. You can provide factory functions everywhere and they infect the whole call graph (though this seems to be "idiomatic"), or make a special method that ignores its receiver and call that on a zero instance of the type, which is more hacky but closer to how free functions can be resolved by type. There's no reason this should be limited to constructors, that's just the easiest example to explain, in Rust associated methods are used for all kinds of things. Speaking of which...
* `cmp.Ordered` for custom types. Come on people. We shouldn't still have this much boilerplate to sort/min/max custom types, especially two full years after generics. The new `slices.SortFunc()` is the closest we've ever come, and it's still not associated with the type. We would basically get this for free if both of the above points were solved, but it's also possible we get something else entirely that solves only ordering and not e.g. construction or serialization.
* Enums, especially if the need for exhaustiveness checking could be balanced with Go's values of making code easy to evolve later. When I need them, I use the `interface Foo { isFoo() }` idiom and accept heap boxing overhead, but even the official `deadcode` analysis tool still to this day does not recognize this idiom or support enough configuration to force it to understand. The Go toolchain could at the very least recognize idioms people are using to work around Go's own limitations.
If we had solutions to these problems, I think most Go folks would find enough value in them that they would still be "Go". In fact, I think people would have an easier time consolidating on a new standard way to do things rather than each come up with their own separate workarounds for it.
This is where I feel "The code I write, is going to look like the code written by most other on my team" the least, because that's only true when a Go idiom has some official status, it's not nearly as true for workarounds that the Go team has not yet chosen to either endorse or obsolete.