5 ms·

As someone who drank the Golang koolaid this proposal kind of infuriates me. Time after time, i've had to proselytize that Go is a good language precisely beca

As someone who drank the Golang koolaid this proposal kind of infuriates me. Time after time, i'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. We'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't been terrible advice. In fact, i'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't terrible, and the solution ended up being rather clear and straightforward once I got over my aversion to code generation. We'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'll experience Go nirvana and all will be well. 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'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't sit well with me. 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, 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. 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. If the Go maintainers truly want Go to continue it's current trajectory and not turn into the next overwrought Big Co language they'll have to be as resistant to change from the inside as they are to change from the outside. Edit: reworded first pp

theparanoid 10y ago
I left C++ because of complexity; I don't want it in Go.
aikah 10y ago
> limited meta-programming, Go reflection is one of the most complicated reflection I've ever seen in any language. Go's / C interop is one of the most convoluted implementation in existance. To pretend that Go is simple at first place is a lie. Go is not simple, it has a limited syntax, which is quite not the same. Go will evolve, whether you like it or not, even if it takes a whole new generation of Go developers and maintainers to get there.
- pjmlp 10y ago
  This is what I keep saying, history has proven that languages that eschew complexity and happen to enjoy mainstream adoption, end up turning into the thing they were fighting against.
Merovius 10y ago
> 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.

theparanoid 10y ago

I left C++ because of complexity; I don't want it in Go.

aikah 10y ago

> limited meta-programming, Go reflection is one of the most complicated reflection I've ever seen in any language. Go's / C interop is one of the most convoluted implementation in existance. To pretend that Go is simple at first place is a lie. Go is not simple, it has a limited syntax, which is quite not the same. Go will evolve, whether you like it or not, even if it takes a whole new generation of Go developers and maintainers to get there.

pjmlp 10y ago
This is what I keep saying, history has proven that languages that eschew complexity and happen to enjoy mainstream adoption, end up turning into the thing they were fighting against.

Merovius 10y ago

> 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.