Another poster already pointed out that you can call methods on value types, but you can also satisfy interfaces with primitive types. The bulk of your post is dogma, ironically.
Specifically, I ran into this when I was using a database library. Values that can be converted to a database-friendly format implement sql.Valuer. However, the library functions just took interface{} instead of sql.Valuer because primitive types could not implement sql.Valuer. Can they implement it now?
Btw, you don't get a free pass at my other objections just because someone poked a hole in one of them. The other problems still stand. Take them one by one.
Let's say library A decides to add func (i int) MyMethod() and library B decides to add func (i int) MyMethod().
Then library C calls i.MyMethod(). Which MyMethod is executed?
You can come up with an answer to that question (e.g. "pick random") but there is no sensible answer.
To avoid this ambiguity you can only add methods to your own types but not someone else's (i.e. not to types defined in other packages or basic types).
> Btw, you don't get a free pass at my other objections just because someone poked a hole in one of them. The other problems still stand. Take them one by one.
You didn't mention other problems, you just whined about Go's feature set. You didn't support your opinions with anything debatable, so there's nothing to discuss.
> the language designers like to pretend it's not exception handling at all.
> You have to name things starting with a capital letter to make them public. Who came up with this convention? It is not shared by any language ever.
> There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites.
func (i myInt) Foo() {}