4 ms·
I love Go, I really do. But there are some issues that should be fixed (maybe in 2.0). I'm not so sure if we really need full-scale generics like in Java or Ru
by JepZ 8y ago
I love Go, I really do. But there are some issues that should be fixed (maybe in 2.0).
I'm not so sure if we really need full-scale generics like in Java or Rust, but the interface system (which is the Go solution for the Generics use-cases) certainly needs some improvements. For example, when you write a container lib which expects an empty interface as input you constantly have to cast the type while using the lib. The result is code which looks awful when you use the container and horrible when you look at the container implementation.
Next, using slices of interfaces is just another bad joke [1]. there might be technical reasons for the current state, but I am sure there are ways to solve those issues.
One thing I am not quite sure about the way Go handles bindings methods to interfaces. Currently, that is not supported and the practical way to do it anyway is to embed the interface into a struct and bind the methods to that struct, but that feels more like a hack than anything else.
Another thing that keeps bugging me is the requirement for map keys to be comparable while that is just some internal property which some types have and others don't. For example, functions are not comparable and therefore you can't use them as map keys. Finding out about such stuff really sucks when functions are considered first-class citizens.
That said, I have to add that I enjoy a lot of the positive sides of Go and while I wish those issue will be fixed someday, I will gladly continue to use it even with those issues.
[1]: https://github.com/golang/go/wiki/InterfaceSlice https://github.com/golang/go/wiki/InterfaceSlice
- dullgiulio 8y agoI don't understand: what do you mean with binding methods to interfaces? Interfaces just represent a bunch of functions that an object must provide (and you can call when you "mask" the object behind the interface).
- JepZ 8y agoWell, normally you bind functions to types like: func (m myType) calcRandom() int { return m.nine } But there are some situations when it would be useful to be able also bind functions to interfaces (e.g. some of them are similar to use-cases for abstract classes in OOP): func (i myInterface) calcRandom() int { return i.Nine() } While I would consider it a clean language design to be able to do that too, it brings some additional complexity and as we know Golang doesn't like complexity. As I said, I am not completely sure of the consequences such a change would bring with it and if it would enable bad practices. So I would not push too hard for that one, but some of the other issues I mentioned are issues of which I am pretty sure that they should be fixed.
- marcus_holmes 8y agoum.. I think you've confused the interface and the implementation. Interfaces are not the same thing as classes, and bringing anything from OOP to them will almost certainly result in Bad Things.