Codebase Refactoring with Go
As someone who drank the Golang koolaid this proposal kind of infuriates me.<p>Time after time, i&#x27;ve had to proselytize that Go is a good language precisely because of its simplicity and restrictions. Simple, explicit, easy to write, easy to understand, and most importantly easy to maintain code is the payoff for not having generics, not having syntax niceties, limited meta-programming, having to type out boilerplate, etc. etc.<p>We&#x27;ve been continually told that our use cases for missing features are just opportunities to explore the existing tooling to solve our problems, and to be honest it really hasn&#x27;t been terrible advice. In fact, i&#x27;ve used the existing go tooling myself at work to do semi-large scale refactoring of the kind that aliases are supposed to solve. It wasn&#x27;t terrible, and the solution ended up being rather clear and straightforward once I got over my aversion to code generation.<p>We&#x27;ve also been told that we need to program better to get the most out of Go... use interfaces, version APIs and include that versioning in import paths, separate concerns religiously, almost fanatically. If we just follow these rules then we&#x27;ll experience Go nirvana and all will be well.<p>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. A feature that doesn&#x27;t even apply to most users of the language (the original argument for type aliases was for refactoring of extremely large codebases). Type aliasing seems like a huge outlier in the KISS philosophy of Go, and regardless of syntax or technical concerns the fact that Google can on a whim break all of their previous Ivory Tower positions that us plebes have had to deal with doesn&#x27;t sit well with me.<p>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 <i>absolutely necessary</i> for either something in the Context package or in k8s, i don&#x27;t remember precisely) which magically resolved itself without aliases, and the very first PR (for some experimental GUI package) using aliases was an example of <i>exactly</i> 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.<p>I guess I shouldn&#x27;t be surprised at this, but I&#x27;m pretty disappointed that it&#x27;s already happening when we&#x27;re still in 1.0. If the Go maintainers truly want Go to continue it&#x27;s current trajectory and not turn into the next overwrought Big Co language they&#x27;ll have to be as resistant to change from the inside as they are to change from the outside.<p>Edit: reworded first pp