6 ms·
> that layer of cruft will never be removed, realistically. It will if you mark the alias as deprecated. Unfortunately, there seems to be no standard way to do
by evincarofautumn 10y ago
> that layer of cruft will never be removed, realistically.
It will if you mark the alias as deprecated. Unfortunately, there seems to be no standard way to do that in Go.
- zaphar 10y agoI have worked on codebases where the deprecated annotation lasted years in the wild. Marking something as deprecated does almost nothing to make it possible to remove code. It doesn't even do all that much to prevent new uses most of the time. Preventing it in the first place is a much more effective method.
- evincarofautumn 10y agoSure, my comment is only meaningful if someone bothers to fix the warnings. Before Vendan’s comment I didn’t know that Go doesn’t have warnings, so it’s moot anyway. I was thinking in terms of upgrading a library to a newer version. It’s nice to at least get warnings for everything you’ll need to update, even if it doesn’t make it any easier to actually do so.
- zaphar 10y agoYeah. Part of the problem that Go attempts to fix is exactly this. They just make it fail to compile if you don't update your code. In a large monolithic repository this is easier to police and manage. In the rest of the world not so much.
- Vendan 10y agoHow would you possibly do that? Part of Go is that there are no warnings, only errors. If you want it to just error a build if you've "deprecated" a thing, just delete the thing...
- danaliv 10y agoIf I've learned anything in nearly 20 years of professional software development, it's that nothing is temporary, least of all things that are explicitly labeled as such.