> We've been continually told that our use cases for missing features are just opportunities to explore the existing tooling to solve our problems The proposal

> We've been continually told that our use cases for missing features are just opportunities to explore the existing tooling to solve our problems The proposal pretty clearly explains, why tooling isn't a solution. > And yet when it comes time to practice what they preach, instead of having to take the same path as everyone else, Google just throws its weight around as de facto owners of the language and adds a feature to make their lives easier. I tried debunking this before. Google really doesn't need this. It makes their live easier, yes, but they can do without. Most people can not do without, because they do not develop in a Monorepo, which is a strict requirement to be able to solve these problems at all. I'm not saying that this is purely altruistic, it definitely makes things easier for people at Google. But the meme that this is bad for everyone and good only for Google is just plain wrong; it makes things easier for Google and possible for everyone else. > A feature that doesn't even apply to most users of the language (the original argument for type aliases was for refactoring of extremely large codebases) The repository of all open source code is an extremely large codebase (it's larger than even Google's internal code base) that'll profit immensely from aliases and contains probably a majority of go users. > Oh, and lets not forget that there was some sketchiness about the technical reasons for wanting type aliases at the beginning (we were told it was absolutely necessary for either something in the Context package or in k8s, i don't remember precisely) which magically resolved itself without aliases I don't know where you are getting your information, but nothing has resolved itself so far, much less magically. Most central users of context are still (after almost four months) not using the stdlib context package, because this situation isn't resolved yet, see e.g. https://github.com/grpc/grpc-go/issues/711 https://github.com/grpc/grpc-go/issues/711 and the issues linked from there. > and the very first PR (for some experimental GUI package) using aliases was an example of exactly the kind of poor practices that aliases allow, which we were assured was never going to happen because Google would only use aliases in the std lib if absolutely necessary. It wasn't an experimental GUI package, it was golang.org/x/image/draw (specifically https://go-review.googlesource.com/#/c/32145/ https://go-review.googlesource.com/#/c/32145/), which is serving as a drop-in replacement of image/draw. And I don't believe it's at all clear-cut that this is a "poor practice"; it is an unforeseen use case, yes, but it's also a very practical one. Being able to augment other people's packages with a drop-in wrapper like that will encourage code-reuse, as it gets easier to re-package other people's code in a better API. Crappy APIs sure as hell are the main reason I don't use much third-party code and I am very excited if it becomes possible to provide these kinds of wrappers. The technical merits of this, btw, also where clearly documented. (Also, nit: golang.org/x/image/draw isn't in the stdlib) > I guess I shouldn't be surprised at this, but I'm pretty disappointed that it's already happening when we're still in 1.0. nit: We haven't been in 1.0 for 3½ years. There is another way to frame this (and other issues) that I consider closer to the truth (though it's of course less anti-Corporation): Which is that Google's size (or rather it's holistic view on a codebase of that size) allows it to better predict the needs of the industry and community as a whole. It is easily illustrated with go as a whole. You can see it as "Google needed their own language, so they developed go, ignoring what everyone else wanted". But that view just doesn't hold up with reality. If that was the case, they wouldn't have open sourced it (and internal adoption would be much higher than it is). But it makes more sense, when viewed from a different angle: They saw where computing and software development is headed, that more stuff will run in the cloud in the future and that work is going to get scaled with networked services, instead of beefier machines. So they developed a language to better support those use cases. Yes, they also profited personally, because those use cases are theirs. But they predicted that other companies and the industry as a whole is going to move in that direction too, so they open sourced it. And so far, go's more than decent adoption in the cloud space does seem to indicate that their prediction is right. And remember how go was perceived in the beginning (and in part still is) by the PL community: As a dinosaur language from the 80s that isn't supposed to be taken seriously. No one, at the time, would have expected there to be a market for this. It's similar with aliases. Yes, they make the life of Googlers simpler. But, in the end, there needs to be a language-agnostic good tool internally anyway, as there are a lot of production languages there. But they noticed that this is a problem they are having, so they want to built a solution, because they anticipate that other people will have similar problems in the future even if they don't see it yet.