(half joke aside, it is finally coming in a couple days.. which I have been saying for quite some time to the extent that my peeps don't even trust me anymore.. 3 things are coming and it is genuinely research grade apparently, for the amount of research I am aware that is released publicly. I really don't know how people ship things, the tooling I see is terrible, or maybe I have NIH syndrome...)

What you do not seem to understand is that with a normal Android distribution, you expect a phone home tied to the manufacturer of your phone.

Matter fact, as I pointed to you but you conveniently ignored, it does not have to be an 'Android' phone. It is the same for Apple and their iphones and pretty much all off the shelf phones. Not need to single out Android if your point is not about the fact that I said 'bootleg' Android...

With a bootleg Android, you forego any security, beyond the phone home. ANd you wouldn't even find someone to speak to about it. What is so difficult to understand?

If your worry is about phone-home, no need to mention Android specifically. This happens with all off the shelf phones. Point is about a phone that has an OS that looks like what you would expect and just doesn't do what you expect. Obviously you didn't understand what I had written so I had to call you on that. You may feel insulted, does not mean that I am insulting you.

Anyway, just so that it is clear. Probably should end the conversation here so no one feels insulted any further.

Besides, depending on the actual OSI license, you can definitely have bootlegs if you really care to argue.

A bootleg does not need to be exploited commercially. It can just be counterfeit.

I am not insulting you. I am telling you that you are being overly pedantic while being wrong at the same time. You might find this difficult to accept but I'm just calling it.

So even if generics were there from the 'get-go', I am not sure this exact feature would be added anyway. In fact, it is mostly contrary to Go's structural polymorphism, let alone parametric polymorphism.

Typically what you want would be defined as a function, a specific wrapper type... If it is not already a common method of each shape.

So far, I don't feel like the design of Go's generics suffers from any real issue. The implementation is not 100 percent done yet. But the plan looks sound to me.

The future lies in a large, local-friendly ecosystem and the hardware to support it.

Gate keeping software makes even less sense nowadays.

The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.

I'm a bit intrigued by this: how would that work with compatibility between libraries, separate compilation and what not? My first instinct is that it would not be a good idea but I might be missing something..?

What use case do you have in mind?