I think that is largely due to the code compatibility guarantee. Maybe that wouldn't have been possible with an extension to interfaces?
Conversation
Replying to
I would change "Why not use interfaces instead of contracts?" to "Why not use contracts instead of interfaces?" and throw away interfaces. I don't like how they did interfaces. It would be nicer to be able to use a subset of (methods in) contracts as dynamic objects instead.
1
Replying to
That's an interesting point. If they made contracts a strict superset of interfaces, new code could use contracts for the same purpose and interfaces could eventually be deprecated.
1
3
Replying to
I don't agree with a lot of the details / choices when considering it from a fresh language design perspective but of course there are a lot of backwards compatibility issues and existing design choices leading it to be this way. It's really not how I would approach this though.
1
1
Primitive types and user-defined types being totally different and requiring totally different code to work with them is very ugly and makes me feel like I'm dealing with Java. This proposal doubles down on that instead of at least not making an existing problem any worse.
2
1
So, for example, with both the existing interfaces and these contracts (which I think should really be 1 feature) you end up needing to define wrappers, with everyone defining their own, and needing to implement these methods over and over again. I don't really understand it.
1
1
There's serious a need for the standard library to define some basic contracts and provide wrappers around the built-in types so people can reuse those instead of making their own. However, this smells a lot like Java. I don't see any benefits from forcing both int and Integer.
1
So, once you have those standard types, the next step on the Java path is to provide auto-conversion to and from them for convenience since it's painful. These are solutions to an unnecessarily created problem though. In terms of deciding between boxing and specialized code...
1
1
... Swift generics simply treat that as an optimization decision, which you can force. It can either reuse the code or specialize it. It also doesn't need to actually force boxing (heap allocation for indirection), but rather it can be generic across different sizes of types.
1
Another major example of an unnecessarily self-inflicted wound is having nullable pointers by default instead of not supporting implicit zero init or assigning nil, and then not having null pointer dereferences except when opting into to nullable pointers. I just don't get it.
1
1
Clearly need an equivalent to Swift (vs. Objective-C) or Kotlin (vs. Java) for the Go ecosystem providing a well designed modern language interoperable with it without all the backwards compatibility warts. Interested to see what happens with it having (ugly) generics though.
A lot of people have told me they use Go because it doesn't have generics or because it's not like C++ with features piled on in ways that conflict and don't work well together. To me, that describes the situation well, especially the Java-like issues with primitive types...
1
1
Replying to
For me, simplicity of language and build speed with reasonable runtime performance have been the biggest drivers. I also haven’t used generics since C++ templates long ago (and don’t want to go back to it). So, I’ve been wary of generics designs that change the reasons I use go.
1
Show replies