An interesting perspective - I'm not sure I agree with some of these examples though, I think they run counter to the culture of Go, which is mostly based on simplicity. To take one example:
Wrap all primitives and Strings in classes
I don't think it's useful to wrap integers and strings in types, it's a level of indirection that's not required except in very extreme cases. Defining a type for productID would be a very odd thing to do in most cases I imagine, especially if it only has one or two methods. Why not have methods on the containing type instead which manipulate productID as required?
I don't think it's useful to wrap integers and strings in types, it's a level of indirection that's not required except in very extreme cases. Defining a type for productID would be a very odd thing to do in most cases I imagine, especially if it only has one or two methods. Why not have methods on the containing type instead which manipulate productID as required?